k'v 




Dr. Dobb’s 


y SOURCEBOOK 


Inside the VESA 2.0 
Linear Frame Butler 



■ COLLISION DETECTION PROTECT YOURSELFI 


■ THEATRIX C++ GAME LIBRARY 


mnm mtusmm 

contbacts 



14.95 ($5.9$ CANADA) 


0 "70989 35567 5 " 

A Miller Freeman Publication 


WinG ft VIDEO FOR 

ATTACHED SPRITES 

SOUND, 

MUSIC, 

AND MOREI 


OBJECTS OR 
EKTENlIOi 





















OuEside North America, cal? Ma 443-4990. IBM, OS/2, AIX, and AS/400 are registered trademarks of Ihe International Business Machines Gorporabon © IBM Carp All righls reserved. 


ff 




Five days. 
Four platforms. 
New Orleans. 

(sleep later) 



After all, the human body can 
go days without sleep. You've proved 
that writing code. So live it up for a few 
days in the Big Easy. 

Start by signing up lor The IBM® Technical 
Interchange, May 21-25, where you"!! learn 
top to bottom the ins and outs of OS/2f AlXf 
AS/400,® and MVS. That’s four featured plat¬ 
forms at once, an IBM first. 

I ^ * With over 600 sessions, you’ll 

get the scoop on everything from object- 
oriented designs, to building and writing 
more efficient C++ applications. See it all. 
Live and unccnsored. Just like New Orleans. 
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Attending the Interchange is easy. Just call I 800 872-7109, 
or in Canada, I 800 661-2131. And we’ll see ya in N’Awlins. 




$1 


Over 100 hardware and software vendors 
will demonstrate the latest innovations in 
s each product. By then, you’ll be 
pumped and ready to try the stuff 
out yourself. We’ll have a special “Test- 
Drive Center” set up and ready to go, with 
technical assistance available one-on-one, 
should you need any help. 

And that’s not all. Well even 
irow in an official IBM Technical 
I nterchange hag loaded with software, tools, 
and leading publications. It can serve as a 
reminder of your know ledge-filled excursion, 
after you catch up on your sleep. 
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Introducing 3D Studio Release 4. Don’t get us wrong, with all its enhance¬ 
ments, like inverse kinematics and fast preview rendering, 3D Studio could plaster this 
page with mind-blowing visuals. But features are only half the story. The other half 
is the fact that more plug-ins are coining out for it faster (about one a week) than for 
any other animation software. From the top names like Pennello™ from Xaos Tools, 



Kai’s Power Tools* 1 from HSC Software, and dozens of powerful effects by Schreiber Instruments, Which 
means you’ll not only be doing things typically reserved for high-end workstations today, you’ll be doing the 
hottest things in this magazine tomorrow. By the way since a flat, static page is no way to demonstr ate th e 
power and flexibility of 3D Studio software for the PC, here’s a suggestion. Get a Free Video , 
3D Studio plug-in guide and the name of your nearest Authorized Autodesk Multimedia Dealer by calling 
1-800-879-4233* and asking for VideoPak M212, Of course, if you were 
to call your dealer and upgrade now, you'd find that very convincing, too. 


Autodesk 


'Outside riie M s, uml CuriutK fits us at M1&491-&31], 
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EDITORIAL 


Teacher, Teacher, I Declare... 

I f there’s one place computer games have made inroads, it’s in education. That’s 
not to say you can expect to see grandmotherly fourth-grade teachers using 
DOOM or Myst to teach geography. (If the truth were known, young minds 
probably wouldn’t object.) Instead, you’re more likely to find games such as the 
venerable The Oregon Trail playing an integral part of an elementary history 
curriculum. The Oregon Trail , originally developed by the Minnesota Department of 
Education and now under the auspices of the for-profit MECG, has been adopted by 
more than one-third of all L'.S. school districts. Most recently, the game was updated 
to include die Mormon anti California trails, all delivered on CD-ROM. 

Games such as The Oregon Trail aren’t feeing used sdely in schools. The home 
software market is booming, with games and home-education software leading the 
pack. According to the $PA : home-education software .sales are up more than 50 percent 
over last year. Fueling this growth are PCs. which have found their way into 33 percent 
of U.S. homes. With sales growth four times die industry average, home-education 
software is currently the fastest-growing category of software sales. 

This surge in home-education software is lx>th good and bad news. On one hand, 
the trend indicates that many parents are interested enough in their children's well¬ 
being to invest in PCs and supplemental educational materials. On the other hand, 
you could say the trend reflects widespread skepticism of schools' performance. 

The biggest game in tow n for the upper grades Is the Internet, in melding technology 
and education, students and teachers are finding that using the Internet as an 
educational resource is fast, fun, and relatively easy. Students can access the most up-to- 
date information, which traditional textbooks won't provide for years to come — if ever. 

Interestingly, schools are also leading the way in some Internet-related scenarios. 
The Independence, MO, School District, for instance, is the first public district in the 
nation using wireless communication to provide Internet services to remote sites. 
Instead of spending $ 150,000 per year to link 25 buildings to the Internet, the school 
system leases a dedicated line from the phone company for $5000 per year. That line 
is connected to the district host, which in turn broadcasts Internet services via an 
antenna to other district buildings. Students use the system for everything from asking 
teachers questions via e-mail to researching and submitting homework assignments. 

The Independence experiment has been funded in part by a stale grant of S80,000. 
For the past few r years, state and federal agencies have been pumping a lot of money 
into K—12 programs that have an eye towards technology In fiscal 1995 alone. Congress 
has committed $40 million to link technology w ith improvement in education. The 
Federal government provides about $750 million for purchasing educationally related 
computer hardware and softw are. Add to this another S450 million from Title I funds 
for hardware/software, and all of a sudden we’re talking real money. 

Granted, some or this money has been spent unwisely (I recently read about one 
school-district warehouse stuffed to the gunnels with brand new, never- unboxed 
80286-based PCs). Still, if we’re going to waste money. I d just as soon see it frittered 
away on education than, say, exorbitant Congressional pension plans or franking 
privileges (or, for that matter, “educational" television shows starring Congressional 
leaders), Nevertheless, education/technology programs may tie in for some hard times 
in the coming months as Congress goes about reevaluating how it will divvy up our 
education-allocated dollars. Every education-related committee in the House and 
Senate will be review ing programs, and cuts w ill likely result. Similarly, upcoming 
changes in telecommunications rules and regulations will impact education programs 
like those in Independence. One of the main telecom issues is whether or not schools 
will be in the running for universal access to the Internet, 

No one said education was supposed to be fiin, but then, no one said it w as 
supposed to be a shuttlecock, batted back and forth in high-stake political games 
either. What technology brings to the learning process is not only an efficient means 
of putting students in contact with basic information, but also a familiarity with the 
tools that will be commonplace in the 21st century. In short, when it comes to 
dow nsizing what has grown to l>e an intrusive government, there are better places to 
start than educational programs. 
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Accelerate your 3D Games ySjpi 



Render Vi 


Render Ware Lightning is the only 3D games graphics library to ' 1 1 
be written specifically to support cross-platform 3D games 
development. 

Every 3D console and PC based 3D accelerator card has its own 
quirks and problems, Render Ware Lightning insulates the 3D 
games developer from these issues and also provides a very fast 
software rendering solution on PCs that don’t have a 3D 
accelerator card. 


*Gn PCs, Render Ware Lightning delivers real-time 3D graphics 
rendering, without the need for a hardware accelerator. Although 
when ft detects the presence of a 3D accelerator it transparently 
accelerates games to even higher levels of performance. 

Render Ware Lightning is: Now available for: 

Lightweight (<20GK in size) DOS 

Lightning Fast Sony PSX 

.Lightspeed development tool Windows 3.1 

Windows 95 
Sega Saturn 
(available soon) 



criterion 


ft 19-35 Criterion Software Limited 
AH rights 'egeru^d 


SEE FOR YOURSELF - Demos and information are available ffcm ftp.csl.com. and 
http://www.csl.com./csIhome.htrnL You can email questions to rw-info@csf.com. 

Render tore Lightning is available with a 30 day no quibble money bade guarantee. 

To order Render Ware Lightning - Tel: 408 749 0493 Fax: 408 732 3057 Email: orders csl.com . 

* Personal License. 1 platform 

RenderWare lightning is a registered trademark of Canon inc, All other trademarks acknowledged 
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Just yesterday Arleen did a 
fly-by of Mars, gave orders to 
a giant microprocessor and 
constructed a seismologically- 
sound skyscraper. Meanwhile, 
Dad played with 


the robots. 




You and the whole family can find fun things to do at The Tech. 145 W San Carlos St., San Jose, CA. Or call 408-279-7150. 


Created by Winkler McManus 



































COLUSION DETECTION 


Collision Detection 


C ollision detection is fundamental 
to most fast-action arcade games. 
After all, the program has to know 
when a missile slams into an alien 
spaceship or when the giant frog 
leaps onto a player. If coded incorrectly, 
however, collision detection can take an 
inordinate amount of time, decrease the 
animation frame rate, and rum an other¬ 
wise enjoyable game, [n this article. Ill 
examine die basic collision-detection prob¬ 
lem, describe situations that can cause col¬ 
lision-detection code to run slowly, and 
suggest ways to keep your code skipping 
along. 

Explosive Growth 

There are two main reasons why collision- 
detection code runs slowly; Either die code 
performs more collision tests than 
necessary or the individual collision 
tests themselves are slow. For die first 
case, imagine a game with two ob¬ 
jects on the Field of play. You want 
to determine if the objects have col¬ 
lided. With only two objects, colli¬ 
sion detection is easy—you simply 
test whether object! is touching ob- 
ject2 or object2 Ls touching object 1, 

One of these tests is obviously re¬ 
dundant— if object 1 is touching ob¬ 
jects, then object2 is also touching 
object!. 

A game with three objects requires 
three collision tests; object 1 with ol> 
ject2, object 1 with object3, and ob- 
ject2 with object 3- With four objects 
the number of tests increases to six. 


Dave is the author of PC Game Pro¬ 
gramming Explorer (Coriolis Group 
Books , 1994). He can be reached via 
CompuServe at 75572,215L 


Getting the most 
out of your 
collision tests 


Dave Roberts 


Table 1 shows how many tests must be 
performed to check from 2 to 20 objects, 
The numbers were derived from the for¬ 
mula (n 1 — n)/2 where n is the number 
of objects; given n objects, you can de¬ 
termine which objects collide by exhaus¬ 
tively performing n 2 tests. Since you don't 


compare an object with itself, you elimi¬ 
nate n tests, giving rr-m And since test¬ 
ing object x with object y is the same as 
testing object y with object x t you elimi¬ 
nate half of die remaining tests, yielding 
the Final formula. 

Onotation describes how the run-time 
or memory requirements of a problem 
grow as die number of inputs or outputs, 
n, changes. In this case, n is the number 
of game objects for which you must cal¬ 
culate collision status, so the algorithm 
is O(n^). As n increases, the number of 
required tests increases in roughly the 
same way as n 2 , and die run time of the 
collision-testing code increases at a rate 
of roughly nr. 

This means that having several objects 
active at once can slow your collision- 
testing code if you aren't careful. 
Doubling the number of objects 
on the screen roughly quadruples 
the number of tests you must per¬ 
form. But it could be worse: Al¬ 
gorithms that are Q(rc 3 ) or 0(2*0 
increase run time much more 
quickly. Of course, it could also 
be better: An O(n) algorithm in¬ 
creases at a constant rate depend¬ 
ing on how many inputs are fed 
to it. Doubling the number of in¬ 
puts doubles die run time. An 0(1) 
algorithm is pure joy because it 
runs at the same rate no matter 
how many inputs are fed to it. 

Eliminating Collision Tests 

Techniques for reducing the 
number of collision tests include 
game-rule elimination and elimi¬ 
nations based on spatial position 
such as axis sorting and the sec¬ 
tor method. 
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COLLISION DETECTION 


Game rules typically dictate which ob¬ 
jects are allowed to collide. Consequent¬ 
ly, you can reduce the number of colli¬ 
sion tests. For instance, imagine writing a 
game where the player controls a space¬ 
ship that shoot s aliens. Since you s re the 
programmer, you make the rules. You may 
decide that aliens can't collide with each 
other and that die player’s ship can t col¬ 
lide with its own missiles. Alien missiles 
probably won’t hit aliens. Player missiles 
won't hit other player missiles and alien 
missiles won’t hit other alien missiles, al¬ 
though perhaps you should allow player 
missiles to hit other alien missiles. 

Now assume that you have 1 player 
spaceship, 5 player missiles, 20 aliens, and 
10 alien missiles all active in the game at 
a given point in time. That’s 36 total ob¬ 
jects, which would require 1296 tests (ra 2 ) 
if every object had to be compared with 
every other object. Our formula reduces 
that to 630 tests ((n 2 -n)/ 2), but taking the 
game rules into account reduces this num¬ 
ber even further. 

The game rules dictate that the player 
spaceship must be tested against each 
alien (20 tests) and each alien missile (10 
tests); the player missiles must be tested 
against the aliens (100 tests) and the alien 
missiles (50 tests), Thais it—180 tests to¬ 
tal Since aliens, player missiles, and alien 
missiles can t collide with objects of the 
same type* 450 tests (71 percent) of the 
630 tests are eliminated. 

The real advantage Lo this approach can 
be seen when you add one more alien to 
the screen. Using die original formula, this 
would require an increase of 36 tests; but 
because of the game rules, only six must 
be added (the alien tested against the play¬ 
er spaceship and each player missile), 

Spatial-Test Elimination 

Some game rules require that every ob¬ 
ject be tested with every other one. In 
such situations, its best to use spatial-test 
elimination techniques. 

Spatial-test elimination works by sort¬ 
ing game objects according to their posi¬ 
tion on the screen or play field (if die play 


Objects 

Collision Tests 

a 

1 

3 

3 

4 

6 

5 

10 

6 

15 

7 

21 

8 

28 

9 

36 

10 

45 

15 

105 

20 

190 


Table 1: Num ber of collision-detection 
tests that must be performed for a 
given number of objects. 


Having several 
objects active at once 
can greatly slow your 
collision-testing code 


field is latger than the screen itself). Ob¬ 
jects are then tested for collisions with oili¬ 
er objects near them. Objects farther aw ay 
are not tested because they could not pos¬ 
sibly be colliding. 

Spatial elimination requires extra com¬ 
putation to sort the various objects and 
perform additional bookkeeping. The key 
is to make the bookkeeping run quickly 
and eliminate as many tests as possible. 
When bookkeeping saves more time than 
it adds, spatial elimination Is worth die ef¬ 
fort. It is better suited for games in which 
a large number of objects are active at 
once. If a game has only a few objects, 
diere aren't many potential collision tests 
to eliminate, and the added bookkeeping 
can exceed the gain. 

Axis Sorting 

When many sprites are on die screen at 
one time, they are rarely at the same lo¬ 
cation* An easy way to eliminate collision 
tests is to sort die sprites in ascending or¬ 
der using each sprite's x- or y-axis coor¬ 
dinate as a key. To check for collisions, 
simply test a given sprite with the next 
few on die list. Stop testing sprites when 
you reach a sprite further down the list 
whose location has a key greater than die 
location of die first sprite, plus its width 
or height. For example, suppose you have 
five sprites (as in Table 2) sorted accord¬ 
ing to their x-coordinates, First, you’d test 
sprite #1 with sprite ^2, then with sprite 
#3. At sprite #4, you'd stop because sprite 
*4 Is located at x-coordinate 40 and sprite 
#Ts right side is located at x-coordinate 
19 (x-coordinate 10 +uddih of 10—IX Since 
every sprite after sprite #4 has an x- 
coordinate greater than sprite *4, there is 
no need to check any further. You'd then 
continue with sprite #2, and so on, for a 



Table 2: Sprites sorted in ascending 
order by x-coordinate. 


total of four tests. Listing One (page 10) 
is an implementation of this method. 

This mediod relies on the assumption 
that sprites are usually distributed across 
the screen. If the sprites are closely 
grouped togedier along the soiling axis, 
this method will degenerate to the 
situation. 

You could just as easily sort the sprites 
by y-coordinate. Since the y-resolution of 
the screen is usually less, however, using 
the x-coordinate tends to spread out the 
sprites. Before using either coordinate axis 
for this method, you should examine your 
situation to determine which axis w ill give 
you better results in general. 

T haven’t covered actual techniques for 
sorting the sprites because this is an im¬ 
plementation issue that varies depending 
on how the sprites in foe game move, A 
common technique is to keep a doubly 
linked list of sprites in sorted order at all 
times. After the movement routine calcu¬ 
lates the sprite's new position for the next 
animation frame, it moves the sprite for¬ 
ward or backward in foe linked list to keep 
it sorted. Typically, a sprite's position will 
only move a few pixels per frame, leading 
to only one or two position changes rela¬ 
tive to foe other sprites in die linked list. 
Frequently, no position changes will be 
needed, Note that general-purpose sorting 
routines are not usually necessary or even 
beneficial. Most of the time, the linked list 
is nearly sorted anyway. General-purpose 
sorts like quicksort are overkill and can 
even show their worst-case running times 
when the objects are nearly sorted 

The Sector Method 

The sector method divides the screen or 
play field into a grid of sectors. In the sim¬ 
plest case, the screen is divided into quad¬ 
rants, You determine which sector each 
sprite is located in according to its posi¬ 
tion on the screen. You then perform stan¬ 
dard collision testing among all die sprites 
within a given sector. Assuming that sprites 
are usually well distributed around the 
screen, most sectors will only contain a 
few sprites; some may not contain any. 
For instance. Figure l shows 6 sprites on 
a screen divided into 16 sectors, Sprites 
“1 and -2 are located in the same sector 
and would be tested against each other; 
die same goes for sprites #4 and #5, Sprite 
#3 is ail alone in its sector and would not 
be tested against anything. 

The primary difficulty of the sector 
method is in handling sprites that fall into 
more than one sector— sprite #6 T for in¬ 
stance, Typically, the sprite is included in 
all sectors it covers. As long as sprites are 
smaller than sectors, a single sprite can 
only be located in one to four sectors. The 
locations of die sprite’s corners determine 
in which sectors the sprite is located. If 
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sprites can be larger than individual sec- 
tors, determining which sectors a sprite 
covers can involve more calculations. 

Try to make sector widths and heights 
a power of 2 larger than the maximum 
size of the sprites. This approach makes 
determining a sprite's sector location much 
easier because you can simply divide its 
coordinate values by a power of 2, Di¬ 
viding by a power of 2 is the same as left 
shifting die coordinate value, so no slow 
division instructions or routines need to 
be invoked. Sectors don't have to be 
square; The vertical size of a sector can 
be different than its horizontal size. This 
lets you optimize the number of sectors 
versus the sector size to more closely fit 
the needs of your particular game, 

Hybrid Techniques 

Sometimes no single technique can ac¬ 
ceptably reduce the number of collision 
tests. This happens when many sprites dus¬ 
ter around each other. Using both game 
rules and spatial techniques can help out 
in these cases. For instance, if you're us¬ 
ing die sector technique and find that many 
sprites end up in the same sectors, use 
game rules to reduce the number of colli¬ 
sion tests among sprites within each sector. 

Quick Tests 

Generally, collision-testing methods are 
either bounding or pixel based. Bound¬ 
ing methods are fast, imperfect tests. Pixel- 
based methods are more precise, but 
much slower. Novice game programmers 
often make the mistake of using pixel- 
based methods for all collision tests. Even 
with aggressive test-reduction techniques, 
a pixel-based collision algorithm can slow 
a game down if it's used for every test. 

Bounding methods don’t compare ac¬ 
tual sprite pixels with each other. Instead, 
a geometric object, typically a rectangle, 
is used to represent the sprite object in 
the test. The rectangle is sized to enclose 
just tire pixels that make up the sprite. 
The advantage is that a few simple tests 
can determine whether two rectangles 
touch. Listing Two (page 10) shows how 
to test two rectangles for overlap. The test 
determination takes no more than four 



Figure 1: Six sprites and their sector 
locations , 


The bounding- 
rectangle test may 
indicate a false 
collision if sprites are 
very near each other 


comparisons. In fact, since logical ex¬ 
pressions are evaluated in a short-circuit 
fashion in C T most tests will stop before 
the whole logical expression has been 
evaluated. The order of the tests in List¬ 
ing Two is arbitrary. If objects in a spe¬ 
cific game are typically above and below 
one another and collide horizontally, you 
can put die vertical tests first. Finally, the 
function call may take up much of the 
execution time in Listing Two, You can 
easily make Collision TestRect into a C pre¬ 
processor macro using the ?; ternary op¬ 
erator This allows the test to be expand¬ 
ed inline, saving die time required for a 
function call. 

The only problem w ith bounding meth¬ 
ods is that they are imperfect. Unless your 
sprite is shaped very much like a rectan¬ 
gle, for instance, some pixels enclosed by 
tiie bounding rectangle won't lie a part of 
your sprite. Those pixels may be a part 
of your sprite bitmap, but they are trans¬ 
parent. Technically, diese pixels are not 
part of the object but w ill be considered 
so for the purpose of testing collisions. 
Thus, a collision might be indicated be¬ 
tween two objects when only a few trans¬ 
parent pixels have actually intersected. 

Perfect collision detection requires 
pixel-based collision detection, in which 
the pixels of the bitmap are tested to see 
if they overlap in the current animation 
frame. Some methods use an auxiliary 
buffer, where sprites are drawn into the 
buffer as they are drawn to video mem- 
on,’ and tests are performed as each pix¬ 
el is drawn. This approach requires a lot 
of memory, however, and can slow down 
sprite-draw ing code. 

Another method uses much less mem¬ 
ory by first calculating a collision map for 
each sprite. A collision map is a bitmap 
with one bit representing each pixel in the 
original bitmap, which could be larger, a 
256-color byte-per-pixel bitmap, for in¬ 
stance. For each solid pixel in the original 
bitmap, the corresponding bit of die col¬ 
lision map is set to 1; for each transparent 
pixel, the corresponding bit is set to 0. 


The program takes bytes from the two 
collision maps and aligns them according 
to die original sprites' positions using shifts 
and rolls. A logical AND is then performed 
between the two collision-map bytes. If 
any bits of the result are set to 1, then 
nontransparent pixels are colliding, List¬ 
ing Three (page 10) shows code that tests 
two collision maps. 

Unfortunately, pixel-based collision test¬ 
ing runs slowly. It requires much more code 
than the bounding- rectangie test, and con¬ 
sequently, more run time. The ideal test 
would run as fast as die bounding rectan¬ 
gle test but retain die accuracy of the colli¬ 
sion map test. Fortunately, this is possible. 

Fast and Accurate 

Quick elimination is the secret to fast col¬ 
lision detection. Most collision tests indi¬ 
cate a negative result. If a game runs at 
a frame rate of 20 frames per .second Cfps) 
and two objects collide about once a sec¬ 
ond, that’s only one collision every 20 an¬ 
imation frames. Even if there are many 
objects on screen that collide fairly fre¬ 
quently, a given object doesn't collide 
with most of the others. Therefore, it 
makes no sense to use an accurate but 
slow collision-test mediod for every test. 
A bounding-rectangle collision test can 
determine that two objects aren't any¬ 
where near each other as wed as a pixel- 
based method, and is much faster. The 
only problem is that it will sometimes 
falsely indicate a collision when trans¬ 
parent pixels of the sprite wdthin the 
bounding rectangle overlap. 

Using both a bounding-rectangie test 
and a pixel-based test in tandem yields 
both speed and accuracy. First, the com¬ 
bined algorithm performs a bounding- 
rectangle test. If the sprites don't collide 
(the usual case), then the bounding- 
rectangle test indicates a negative result 
very r quickly and the program proceeds 
to the next pair of sprites. If the bound¬ 
ing-rectangle test indicates a collision, 
however, the program performs a pixel- 
based test to determine whether the 
bounding-rectangle test was correct. The 
pixel-based test runs much more slowly 
than the bounding-rectangle test, but it Is 
invoked infrequently. 
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COLLISION DETECTION 


PROGRAMMERS 

Westwood Studios has been creating 
world class games for 10 years. Some 
of our products include Lands of Lore, 
The Kyrandia series, Dune II and the 
Lion King. 

We are looking for programmers 
with expertise in the following 
areas: 

• 32 bit protected mode (80386/486/P5). 

• 2D and 3D graphics. 

• Video compression. 

• Communications (Modem, Network). 

• Windows/Chicago. 

• CD-ROM (DOS/Windows/Saturn/PSX). 

Requirements include: 


• BS in Computer Science or equivalent 
experience. 

• 3 years C/C++ experience. 

• 2 years assembly language 
experience. 

• Willing to relocate to the Las Vegas 
area. 


We have an excellent working environment, 
extensive benefits, paid vacations and a 
competitive remuneration package. For 
immediate and confidential consideration, please 
send a current resume to: 

Westwood Studios, Attn: DD2, 5333 South 
Arville, Suite 104, Las Vegas, NV 89118-2226, 
by FAX to: (702) 368-0677, or by E-MAIL to: 
careers @ westwood. com 


Westwood 



CIRCLE NO. 6 ON READER SERVICE CARD 


Listing One (Text begins on page 7.) 

typedef struct -SPRITE-DATA t 
struct .SPRITE..DATA * Next; 
int Top: /* sprite location */ 

int Left; 

int Width: /* sprite dimensions •/ 
int Height; 

) SPRITE-DATA; 

/• 

Function: CollisionTestSorted 
Description: 

Tests a linked list of sorted sprites to see if they 
potentially overlap. If so. they are collision tested. 

♦/ 

void CollisionTestSorted(SPRITE_DATA • SpriteList) 

C 

SPRITE-DATA *sl. *s2 : 
int slRight: 

si ■ SpriteList: 
while (si !- NULL) C 

slRight * sl->Left + sl->Width - 1; 

/* Compare 6l with all following sprites until left edge •( 
/* of a following Bprite is located beyond the right *7 
/* edge of s2. *7 
s2 » sl->Next; 

while (s2 !» NULL && (slRight > s2->Left)) ( 

CollisionTest(si. s2): 
s2 « s2->Next; 

) 

si » sl->Next; 

) 

1 

Listing Two 

typedef struct ( 
int Left; 
int Top; 
int Right; 
int Bottom; 

) RECT: 

/• 

Function: CollisionTeatRect 
Description: 

Tests two bounding rectangles to see if they overlap. 
Returns TRUE if so. FALSE otherwise. 

♦/ 

BOOL CollisionTestRect(RECT * rl. RECT ♦ r2) 

( 

if (rl->Left > r2->Right j! r2->Left > rlORight |! 
rl->Top > r2->Bottom !‘ r2->Top > rl->Bottom) ( 
return FALSE: 

) 

else ( 

return TRUE: 

) 


Listing Three 

typedef unsigned int UINT16; 
typedef unsigned char UINT8; 

typedef struct ( 

UINT16 Width: /• sprite pixel width / 8 bits per pixel */ 

UINT16 Height; 

UINT8 Data: /* first byte of variable length data */ 

1 COLLISION-MAP: 

/♦ 

Function: CollisionTestBitmap 
Description: 

Tests two objects using COLLISION-MAPs. The upper left corner 
of each object is specified with (xl. yl) and (x2. y2). 

•/ 

BOOL CollisionTestBitmap 

COLLISION-MAP far • Objectl. 

COLLISION-MAP far * Object2. 

int xl. 

int yl. 

int x2. 

int y2 

) 

( 

UINT8 far • Datal: 

UINT8 far • Data2; 

COLLISION-MAP far • SwapTemp; 

int DeltaX; 

int DeltaY: 

int Shift; 

int Skip: 

UINT16 WidthCounter1; 

UINT16 WidthCounter2; 

UINT16 HeightCounterl: 

UINT16 HeightCounter2; 

UINT8 ObjectlData: 

UINT8 ShiftRegister; 

UINT8 01d0bject2Data: 

UINT8 NewObject2Data: 

UINT8 Fina10bject2Data: 

assert(Objectl f= NULL): 
assert(Object2 != NULL); 
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) 


Delta* = x2 - Kl; 

Deltas = yl - ylj 

/* tfwap objects to sake tbe algocithn work */ 
if {DeltaX i 0} t 

SvapTemp - Objeeil; 

Objectl = ObjectZ; 

Object^ = SvapTejep; 

DeltaX = -Delta*; 

DeltsY = -DeltaYi 

) 


Datal = fUIWrt far *J 4(0bjectl->Data)f 

Cata2 - (UINTfi far *) ifObj*ct2->Data); 


HeigbtCpunter1 = 0: 
HcightCoutLterZ - 0; 


/* flfcip raws off the object with the least Y-value */ 
if (DeitaY > 0) [ 

Data! += Object1-5Width • Delta?; 

HeightCounter1 += Delta?; 

} 

else if (Delta? < f) t 

Data2 Object2->Width * ~Delt*Y; 

HeightCounterS -= Delta?; 


Shift ■ DeltaX % 8; /* amount to shift object 2 data to right +./ 

Skip = Delta* / B; h number of bytes to skip at beginning of */ 

/* object 1 data Lin* */ 


while {HeightCounterl < Ohjectl-iHoight && 

HeightCbunter2 < Object2->Height) [ 

/* potent ielly skip a few bytes 'cause obj 1 is to left of ahj 2 */ 
WidthCounter1 * Skip; 

Datal Skip; 

WidthCounterS = 0: 

OldObjeet2hata = 0; 

while {WidthCotmterl < Object 1-Width kk 
VidthCounter2 < Gbjact 2-Width) f 

/* get data */ 

Object!Data * *Datal++; 

WawObjectZData = *Data2++; 

/“ shift object 2 data to correct delta X differential */ 
ShiftHegieter * ({UIRT163 OldObjectZData « fl) | 

(tflWTlt) MewObjecUOstaj 
ShiftRugiGter '>'>* Shift; 

FinalObjectiData = ShiftRegister & 0*FF: 

f* return if we have a collision, */ 
if (OhjactiData & Flnal0bject2Data} l 
return TRUE; 

1 

OldObjectSData = NewObjECtSData; 

WidthCounterl++; 

WidthCnuhter2 ++ ; 


/* correct pointers at end of line */ 
Datal += Object 1^>Width - WidthCoiinterl; 
Data2 +* Object2->Width - WidthCountera; 

HeightCouncerl++; 

HeightCounteri+^l 


/* ve got through all that with no collision */ 
return FALSE; 


End Listings 



Wc^dgAsyay, 

ARE COMING 


TOGETHER. 

The bunch of on animated, on-line world is about lo 
occur. II will pair interactive multimedia dimensions, the 
social with the graphic. And it will allow CompuServe 
members from North America, Europe, Japan and 150 
countries across the globe to meet, interact and build 
together a virtual community. You con be there when it 
happens. More Importantly, you can help make it hap¬ 
pen, He res haw, 

Fujitsu Limited and CompuServe are embarking on a new 
and exciting multimedia venture entitled, Worlds Away. 

Using client/server design, WorldsAway is a chat room 
that delivers rich graphical animation in a permanent vi¬ 
sual space with shared context for interaction. In real¬ 
time, users' identities -— avatars — can move about the 
space, share and exchange objects, ideas and emo¬ 
tions. And because WoHdsAway is based on a distrib¬ 
uted, object-oriented technology, the service is scaleable 
to accommodate a growing user base. The world can 
be literally expanded, and gateways to new worlds cre¬ 
ated, ad infinitum. 

WoHdsAway is the first product to be introduced through 
Fujitsu's new start-up division, Cultural Technologies, 
formed to develop and market multimedia technologies 
that extend, enhance and facilitate Interaction between 
people and promote global social computing. 

0 A M E S Fujitsu Cultural Technologies 
Division Is now accepting 

mi m ms «% tss resumes from qualified 

m £ O E D l professionals in the following 
areas who are interested in doing breakthrough work in 
the Games industry. 

Multimedia * Software * Development 
• Marketing * Customer Service 

Come make your mark in a world where everyone can 
live. Join us in a venture and an adventure that is 
WoHdsAway. Start by sending your resume, specifying 
area of interest, to: Cultural Technologies, a divi¬ 
sion of Fujitsu Open Systems Solutions, 3055 
Orchard Dr., San Jose, CA 95134-2002. FAX: 
(408) 456-7888. E-mail: janine@ossi.com Prin¬ 
cipals only, EOE, M/F/D/V. 


VISIONARIES 



Cultural 

Technologies 
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© S991 CampuMentt?? 


Some people 
put the homeless out 
of their minds. 
Christine Vigil put 
them on-line. 



In 1906 St, Vincent de Paul was 
Founded to help people left homeless by the 
San Francisco Earthquake. Today, they 1 re 
an organization that helps thousands of 
homeless people nationwide. By finding them 
shelter, medical care, rehabilitation, and jobs. 

That s where Christine came in. 
Before she got involved, St, Vincent de 
Paul worked with 75 other San Francisco 
social service agencies matching homeless 
people with available jobs. The job Finders 
Alliance worked hard, but since they only 
communicated by memo and phone, it 
could take up to three weeks to match a 
qualified person with an open job. 

By using her computer skills, 
Christine was able to put St, Vincents 
on-line, and make the whole process more 
efficient. As a direct result of her efforts, 
today Sc, Vincents has been able to find jobs 
for their people far more rapidly. And make 
better matches, because they have access 
to a comprehensive database. 

Of course Christine is just one 
example. There arc a lot of ways you can 
put your special computer skills to a much 
appreciated use, whether you specialize in 
telecommunications, system debugging, 
or basic software training. To know more, 
call CompuMwtor™ at 1-800-659-3579. 
We 11 put you in touch with a local non¬ 
profit organization whose needs are 
compatible with your area of expertise. 

There are many ways to make a 
difference in the world. Sometimes its 
simply doing what you already do best. 

CompuMentor" 

People helping computers help people. 

89 Stillman Street, San Francisco, CA 94107 






THEATRIX 


Theatrix: 

A C++ Game 

Class Library 



Al is a DDJ contributing editor and 
can he contacted on CompuServe at 
711011262. 


Abstraction 

Theatrix provides several levels of 
interface. Each lower level in the 


P C game programming is currently 
very popular among programmers 
largely because of the over¬ 
whelming success of games such 
as DOOM and MysL Games them¬ 
selves have always been part of the 
personal-computer phenomena. Among 
the first PC games to be widely used were 
Microsoft’s Flight Simulator ; a graphical 
simulation where you fly a Cessna 182, and 
Adventure, a text-mode tour through a cave 
of dragons, dwarfs, mazes, chasms, and 
other imaginative obstacles. Those games 
ran very well on the small PCs of dieir 
Lime— 4.77-MI Iz 8088 machines with 640 
Kbytes of RAM, 360-Kbyte diskette 
drives, and little or no hard-disk space. 

By comparison, today’s desktop ma¬ 
chines are supercomputers, and the 
best contemporary games take hill ad¬ 
vantage of the processing power and 
high-resolution graphics of main¬ 
stream configurations. 

Theatrix is a C++ class library that 
encapsulates the operations of typi¬ 
cal arcade games. The name comes 
from the metaphor that the library 
implements—games are viewed as 
theatrical productions, with directors, 
players, and scenery. You build a 
game by designing these components 
with graphics tools and by deriving 
from the Theatrix classes, modifying 
the behavior of the classes to pro¬ 
vide the actions in the game. An 


The Theatrix library is the subject of a 
book I am writing in association with the 
library’s author Sian Trujillo. Stan brought 
the library to me for my opinion. Its lev¬ 
el of abstraction was impressive: In a cou¬ 
ple of days and with only about 500 lines 
of C++ code, 1 built an arcade-style game 
with background scenery and seven 
sprites that move around the screen In 
the fashion of an animated cartoon. Most 
of the work was the artistic part—de¬ 
signing the scenery and the sprites with 
a paint package. 

The book project came about when we 
realized that a programmer can build a 
comprehensive set of game-creation 
tools from widely available freeware 
and shareware programs. There are 
paint programs, 3 D modelers, ray- 
tracers, image-format converters, 
graphics libraries, sound editors, and 
so on. All that was missing was a 
class library to encapsulate the or¬ 
ganization of the graphical elements 
into a game scenario. Stan’s Theatrix 
library filled that need, and we 
agreed to publish it in a book that 
includes the source code for the li¬ 
brary, several demonstration games, 
and the shareware and freeware 
programs on a companion CD-ROM. 
The book is to be entitled C++ 
Games Programming and will be 
published in mid-1995 by M&T 
Books. 


Encapsulating 

arcade-game 

operations 


event-driven programming model sends 
controller and timer-event messages to the 
game’s directors and players. 
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THEATRIX 


class hierarchy encapsulates and hides 
more of the details of the game imple¬ 
mentation, raising the programmer’s lev¬ 
el of abstraction in his or her view of the 
problem. At the highest level of abstrac¬ 
tion, you create scenes that include play¬ 
ers under the control of directors. You are 
unaware of (and do not care) how the li¬ 
brary manages the low-level details of 
page flipping, z-ordering, sound genera¬ 
tion, and the like. Those details are hid¬ 
den in the Theatrix class implementations. 

In this article, I’ll describe Theatrix at 
its highest level of abstraction and pro¬ 
vide example code that uses the library at 
that level. When the book is available, you 
will be able to use these examples to build 
the simple demo game discussed here, as 
well as others, by using the library and 
tools on the companion CD-ROM. When 
the library is complete, the entire source 
code will be available electronically; see 
“Availability," page 3. 

A Graphics Library 

Tlie lowest level of game control is han¬ 
dled by a graphics video package. To sup¬ 
port the objectives of Theatrix, the pack¬ 
age must lx* able to display full-screen, 
static graphics scenes and superimpose 
smaller frames of graphic sprites at refresh 
rates fast enough to suggest movement— 
to achieve animation. We chose FastGraph, 
a graphics library from Ted Gruber Soft¬ 
ware (Las Vegas, NV) known for its effi¬ 
ciency and performance. To experiment 
with Theatrix classes, you will need at 
least the shareware version of FastGraph. 
which is available for download from the 
graphics forums on CompuServe and oth¬ 
er online services. For serious Theatrix- 
based game development, you should get 
the commercial version of FastGraph. As 
with all shareware programs, the down¬ 
loaded version includes ordering infor¬ 
mation for the registered version. 

A future version of Theatrix will work 
with the graphics APIs of Win32, allowing 
portable games that compile and am on 
both DOS and Windows with few or no 
source-code changes. The same executa¬ 
bles will run with Windows NT, Windows 
95, and Windows 31 with WinG and 
Win32s. That work is underway, but not 
yet ready for widespread consumption. 

Game Action 

A game usually consists of several ancil¬ 
lary' displays—menus, help screens, and 
options screens— but they all eventually 
get dow n to the action. That's the part that 
I'll discuss here. The game’s action is or¬ 
ganized into scenes, w ith each scene un¬ 
der the control of a director. The scene 
director is a game-dependent class derived 
from the Theatrix SceneDirector class. Only 
one scene Is playing out at any given time. 


A games graphical 
elements consist of 
PCX files 

Each scene has a background display and 
one or more players—sprites—derived 
from the Theatrix Player class. Players 
move around the screen and do things in 
response to external events such as 
keystrokes and ticks of the clock. You 
build action into a game by deriving play¬ 
er objects that remember their current, 
game-dependent mode and change their 
mtxles, image, and position at regular in¬ 
tervals based on those modes. Players can 
communicate with one another by using 
messages or simply calling member func¬ 
tions. Players and directors communicate 
w'ith one another in the same ways. 

ITiere are several distinctions between 
the graphical representation of a scene’s 
background and that of the players: The 
background is stationary, occupies the en¬ 
tire screen, and represents the lowest 
(most-distant) z-order; the players are 
smaller, superimposed over the back¬ 
ground, and positioned anywhere on the 
screen. Players move around, maintaining 
distinct z-order relationships with one an¬ 
other and are always in front of the back¬ 
ground. I he z-order determines which 
player passes in front when two players 
intersect on the screen. Players can enter 
and leave the scene through portals 
(doors, for example) defined as dipping 
parameters for the display of the player. 
'Fhere are usually several graphic render¬ 
ings for each player and one image for 
the scene’s background. The player tells 
ITieairlx which player image to display at 
any given interval, and the combination 
of images generates animated sequences. 

Game Timers and Events 

Theatrix uses the 18.2-ticks- per- second 
clock frequency to manage animation. The 
scene director includes an on_tinter func¬ 
tion called at that interval. The players 
each have an update_position function 
that is called at intervals spedfied in num¬ 
bers of ticks. 'I he system automatically 
calls update_position, a virtual member 
function of die Player base class. Players 
and directors may also register to be called 
when external events occur. For example, 
a player may use a specified keystroke to 
initiate an action, such as firing a weapon 
or changing the direction of movement. 
The registration specifies the event and 
the member function in the player’s class 


to lx? called w hen the event occurs. The 
derived Player class declares the registra¬ 
tions with macros. 

Game Architecture 

A Theatrix-based game metaphor usually 
follows this scenario: The game program 
instantiates a derived SceneDirector ob¬ 
ject, wdiich constructs itself and instanti¬ 
ates one or more derived Player objects. 
Tlie director and die players register for 
events with macros at compile time. Each 
player has a z-order based on its order of 
instantiation within the director, and die 
player’s constructor specifies how fre¬ 
quently the player Is to lie called to up¬ 
date its position and image. 

Once every clock dck, Theatrix calls die 
director’s on_tinter function. The director 
monitors the action in die game and sends 
messages to players to tell them what to 
do next. At regular intervals, Theatrix calls 
each player .so that the player can update 
its image and position. 

The director and players respond to 
events for w'hich they have registered. These 
events cause die director and players to 
change either their own mode parameters 
or diose of other elements in tlie game. Tlie 
players’ timer-driven functions respond to 
these modes and call Theatrix functioas to 
change their position and image. 

Inside Theatrix 

Theatrix maintains three screen buffers. 
One always contains a rendering of die 
background scenery with no players in 
view'. This buffer is constant and never 
changes. Its purpose* is to provide screen 
segments of the untouched background 
to effectively erase a player’s current im¬ 
age. Tlie second buffer Is a working buffer 
in w hich Theatrix builds the next screen 
to be displayed. I he third buffer is die 
one diat die user Is cunendy viewing. Most 
Theatrix games use the VGA’s Mode X, 
which has 320x240-pixel resolution, 256 
colors, and three video buffers. Theatrix 
takes advantage of die fact that memory- 
to-memory writes are faster when both 
buffers are video buffers. 

During construction, a scene-director 
object tells Theatrix the name of a PCX 
file that contains its graphical rendering. 
Theatrix uses diis file to build the first ver¬ 
sions of the three buffers. When player 
objects construct, they tell Theatrix the 
name of a file of images that contain the 
animation still frames for the player. The¬ 
atrix reads these image clips and stores 
them in extended memory, if the com¬ 
puter has it, or in conventional memory 
otherwise. Each player may also use an 
optional file of sound clips in Sound 
Blaster VOC format; Theatrix likewise 
stores these clips in extended or conven¬ 
tional memory. These files of image and 
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sound clips are in a Theatrix-specific for¬ 
mat. You build the files with utility pro¬ 
grams that organize the clips into the for¬ 
mat of the database. 

Instantiated players are either on or 
off stage. At each tick of the clock, The¬ 
atrix iterates through the current scene di¬ 
rector's list of on-stage players. If the play¬ 
er's refresh interval has expired, Theatrix 
calls the player’s update_position function 
to allow the player to modify its position 
and image. If the circumstances of the 
game tell the player to make any changes, 
it does so by calling Theatrix functions to 
change its image number, screen coordi¬ 
nates, and possibly its clipping coordi¬ 
nates. These functions only post the 
changed values; they do not take any im¬ 
mediate action on the image itself. When 
tiie player returns, Theatrix uses the play¬ 
er’s updated image number and screen 
position (or existing ones, if no update 
occurred) to superimpose the image onto 
the background in the working screen 
buffer (not the visible one). After iterat¬ 
ing through all the players, Theatrix swaps 
the working screen buffer with the visi¬ 
ble one, which displays the updated frame 
with scenery and all the players in their 
new configurations. 'iTien, while the user 
views the updated screen for an iastant, 
'Ilieatrix iterates through the players again, 
using their current image coordinates and 
size to erase the player’s image by copy¬ 
ing a rectangle from the constant scenery 
buffer to the working buffer. Tliis process 
prepares the working buffer for the next 
refresh frame of the entire scene. 

A scene director can change the z-order 
of its players. It does so by monitoring the 
progress of the action and deciding that 
a player needs a different position in the 
z- coordinate system with respect to the 
other players. Players are maintained in a 
linked list among die director’s data mem¬ 
bers. To change the z-order. the director 
changes the position of a player in the list. 
'Ilieatrix provides interface functions to 
support dlls operation. 

Graphical Elements 

A game’s graphical elements consist of PCX 
files. A scene is a PCX file that fills the 
320x240-pixel screen. Players are repre¬ 
sented by smaller PCX files organized into 
player-oriented graphics databases. Each 
image of a player includes the image’s 256- 
color representation on a solid black back¬ 
ground, which the low- level graphics func¬ 
tion library uses for a transparent color. 
Elements of die background scene display 
through the transparent parts of a player. 
This permits you to build a player of any 
shape in a rectangular PCX file. 

Building those pictures is the biggest 
part of game construction, (although de¬ 
signing a good game scenario is no triv- 


Theatrix provides 
several levels of 
interface 


ial task). Your choice of tools depends on 
your artisdc abilities and the look you want 
for the game. We built some games by us¬ 
ing a paint program to construct all the 
graphical elements, which gave the game 
an arcade look and feel. Years ago, I was 
a newspaper cartoonist, and those skills, 
rusty tiiough diey are, came in handy dur¬ 
ing diis project. 

We built other game graphics by using 
3-D modeling and ray tracing to achieve 
photo-realistic images. Games with sur¬ 
realistic scenery, spacecraft, robots, and 
accurate perspective are best built this 
way, although designing and rendering 
such objects can involve a substantial time 
investment. 

Your choice of a tool for building pic¬ 
tures has no effect on die game’s perfor¬ 
mance, however. To Theatrix, the scenes 
and players are all PCX files that display 
on a 256-color, 320x240-pixel Mode-X 
screen. 

An Example 

Listing One (page 18) is skater.cpp, the 
C++ code tiiat implements a demo of a 
game. Although the game doesn’t do 
much, the code contains all the elements 
of a more-complex game built under The¬ 
atrix. As Figure 1 show's, the game’s back¬ 
ground is a skating pond. There are three 
players in the game: Two of them stand 
still w hile the third skates around them in 


a figure eight. If you press the Enter key, 
the skating player breaks through the ice, 
making a splashing sound. 

Listing One begins by deriving the 
Skater class from Theatrix’s Player class. 
Two data-member integers maintain a step 
count (actually a skid count, since the 
skater is skating) and the current action 
mode. There are eight modes during the 
normal course of the game, representing 
the eight segments of the figure eight, 
which is actually a squared eight to sim¬ 
plify die example. The DECIARE_CUELIST 
macro declares die presence of a list of 
cue registrations that assign event mes¬ 
sages to the class. 'Hie CUELIST macro se¬ 
ries that follows the class declaration de¬ 
clares die cues that the player receives. In 
this case there is only one cue, which oc¬ 
curs when die user presses die Enter key. 
The KEYSTROKE macro specifies a key 
value and a function to execute when the 
key is pressed. This method registers all 
objects of a class for a common set of 
events. Individual objects of a class can 
register odier events independendy of one 
another by calling functions in Theatrix. 
Besides keystroke events, there are timer 
and logical-message events. 

The Skater constructor specifies the 
name of the graphics and sound-effects 
files diat a skater uses to animate itself and 
make sounds. The Skater: :update_ position 
function is called from Theatrix once each 
timer tick to modify the skater’s position 
and image, if appropriate. The function 
tests the mode data member to see w r hat 
to do next. Each segment of die figure eight 
involves an image and a number of steps 
through the x- or y-coordinate, depend¬ 
ing on whether the segment Is horizontal 
or vertical. I built die images in three sizes 
to suggest perspective as the skater gets 
further away from or nearer to the user 
in the figure-eight pattern. 



Figure 1: Sample Theatrix game. 
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THEATRIX 



A tt@w maricef has opened up to 
swns developers across the world! 

A server using Same Connection 

allows gamers to play with 3 or more 
friends without the use of a network. 
With support for 8 of the most popular 
multiplayer games available, it's 
no surprise that hundreds of 

servers are 

linking players around the world. 

Came developers can easily add 

support to their 
games using the Game Connection 
Protocol (GCP). 


See a Server in 

action at the Sirius Software hospitality 
suite at the Game Developer 
Conference in Santa Clara, CA, 
April 22-25. 


For more information, contact: 
Sirius Software, Inc. 

1049 Cardiff Street 
Casper, WY 82609 

Voice: ^<307) 237-C 
BBS: (307) 22^21 12 

FAX: (307) 265-4452 




[f the mode member is greater than 8, 
the user has pressed the Enter key, and 
the skater crashes through the ice. The 
program controls that sequence by incre¬ 
menting modes until it gets to Mode 13 
The program manages all animation se¬ 
quences by calling selxymd setjmageno 
with appropriate parameters for each ex¬ 
ecution of update_ position. 

A Slander class is derived from Player 
to represent the two stationary figures. This 
class shares the graphics file with the Skater 
class, and it has no .sound-effects file. 

The Pond class is derived from The¬ 
atrics SceneDirector class. It declares in¬ 
stances of Slander classes and sets their 
position and image numbers. The Pond 
class also instantiates the Skater object, 
which manages its own representation and 
movement. 

Hie Pond::on_timer function overrides 
SceneDirector s virtual function. The over¬ 
riding function gets called once for each 
timer tick, or approximately 18 times per 
second. Its purpose is to watch the 
progress of the game and give direction 
as needed. In tills case, the on_timer 
function monitors the skater's progress. 
When the skater enters the forward, cen¬ 
ter, or rear lateral segments of the skat¬ 
ing pattern, die director must change the 
skater's z- order so that tiie sprites dis¬ 
play appropriately. Only the director can 
change die z-order, If the player tried to 
do it from within its ttpdate_position 
function, the change could be a prob¬ 
lem. That function is executing from with¬ 
in an iteration through the list of players. 
Changing the z-order changes the se¬ 
quence of players in the list, which could 
have an undesirable side effect on the it¬ 
eration. A player can tell the director to 
change die player's z-order, but only from 
a different function, perhaps an evenL- 
driven one. 

Theatrix is a. good example of the 
powers of abstraction. Listing One con¬ 
tains less than 200 lines of C++ code. 
However, when combined with a sound 
clip and some PCX files, the code im¬ 
plements most of an arcade game's con¬ 
tents. You can download an executable 
version of the skater game and run it to 
see what you can do with Theatrix and 
some shareware utilities. The graphics 
are primitive, roughed out in about an 
hour with a Laptop computer and the 
wonderful NeoPaint shareware program 
from Neosoft (Bend, OR), You could use 
a 3~D modeler and ray tracing to build 
other PCX files and give the game a 
completely different, photorealistic look, 
yet the code would be virtually un¬ 
changed. 


DDJ 

(Listing begins on page 18.) 
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D< Oobd s Journd) 
Mlllei rrseman. Inc 
IMIiiiirits reserved 


Algorithms foi Graphics and 
Image Processing 

Theo Paiiidis 


FAX ORDERS: 510-372-8582 USE THIS ORDER FORM. E-MAIL ORDERS: sbarnes@mfi.com MAIL ORDERS: Dr. Dobb's/CD, 
P.O. Box 1525, Martinez, CA 94553-9802 INTERNATIONAL: USE MAIL, FAX, E-MAIL, OR CALL 415-655-4190 


You cant get more graphic than this. 


Introducing the 

Essential Boohs on Graphics Programming CD- 

from the Dr. Dobb’s CD-ROM Library 


I eed to get up to speed on graphics programming-fast? There’s 
only one definitive source you can turn io-Dr. Dobb s Essential 
Books on Graphics Programming CD-ROM! 

Get seven of the essential books in graphics programming, with full 
text, diagrams, graphics, and source code-all on one CD-ROM. From 
fundamental algorithms to the most complex techniques, this CD- 
ROM lets you find all the critical information you need for your 
graphics programming projects. 


Zen of Graphics 
^Programming 

Michael Abrash j£r t 

s 

Practical Image 
Processing in C 

Craig f intlley j 


Texture mapping, color modeling, and morphing, 
all optimized for speedy 2-D and 3-D graphics 
programming. Practical image acquisition 
and processing. High-quality 3-D photo 
realistic graphics. Digital halftoning. 

Image synthesis and special effects. 

And much more! 

Plus, all the source code on the 
disks supplied with the books 
are included. 

Your CD-ROM comes with 
must-have features: 

• a powerful search engine for 
locating information across all 
or selected books 

• tables of contents and indexes 
hotlinked to their topics 

• copy, bookmark, and notes functions 
And you get a 60-day money-back guarantee! 


Photorealism and j 
Rag Tracing in C 

'n; j*-- 

Watkins , Coy ~~ * - 

and Finlay ~ ' i 


race Art nick 


DigiiarHalftoning 

RoJert ( lichney 


Oigital , -; 


igifal Image Warping 

George Wolberg 


Windows Platform 













THEATRIX 


Listing One (Tex/ begins on page 13 ) 


ft ——— skster.cpp 
#include <theaLti*,h;> 

const int sidesteps = 25: if number of steps ir lateral movement 

const int fvdsteps =12 3 // number Of Steps in front/tear movement 

const int sstepincr = 5: // lateral v, coordinate increments 

const int fstepincr -3; // front/reat y coordinate inrreiBEttts 

// ^ moving gprite 

class Skater : public Player ( 

short int steps; // number of steps taken current segment 

short int mode; // 1-fl ■ skating pattern #; 11-13 - splash 

friend class Pond: 
void QnEnter(int); 
protected; 

DECLARE.CUELIST 
public; 

Skater 0 ; 

virtual "‘Skater (1 { j 
void update_position(); 

): 

// -event message up for Skater class 

CUELIST{Skater) 

KEYSTROKE('Yr'. OnEnter) 

ENDCUELIST 

// —- construct a moving sprite 

Skater:iSkater{) : Player("skater -gf*" r “skater.sf*") 

t 

aeticy(90.i43): // initial position on pond 

set-imagenofl )3 ft first skater ftane 
appear(): 
steps = 0! 
mode =* lj 

3 

// — skater Frame animation entry point (once every tick! 
void Skate r::update w p-osition() 

switch (mode) ( 
cape 1; 
rasa 3: 
case 5: 
case 7: 

// — side to aide movement 
if (t+steps =* sidesteps) £ 
steps = 0; 

sat imagenot++itLade) ; 
break; 

) 

if (mode ft 2) // modes 3 and 7/ to th# left 
s#tx(gEtK() - aatepincr); 
else // modes 1 and 5: to the right 

SEtx(gatx() + astepinct); 
break; 
case 2 : 
case 4; 
case fit 
case 0; 

// front or beck movement 
if f++steps =■ fwdsteps) ( 
steps = 0; 
if (mode “ S) 
mode = 0: 

flet.iuBano(++BodG) ; 
break; 

J 

if (mode i fi] // modes 2 and 4; away from the screen 
satyfgttyO - fstepincr): 

else // modes 6 and 8; toward the screen 

sety(getyC) + fstepincr): 
break: 
case 9: 

setintervai{3): // alov down refresh rate 

set.imageno{13); // 1st frame of ice-breaking splash 
mode+ + ; 

play_HDund_clip£l )i 

break: 
case 10; 

Set. lugesoU2) : // 2nd frame of ice-breaking splash 
mod#++; 
break; 
case 11: 

set_imagena (13-1; // 3rd frame of ice-hrcaking splash 
modo++; 
breaks 
case 12: 

Bet-imagenotM) i t! hole in ica 

BOdG++ E 

steps = 0: 
break; 
default: 

if (steps++ = 30) 
stop-director 0: 
break: 

) 

) 

if pressed Enter, break the ice 
void Skater;:OnEnter(int) 

£ 

If (mode < 9) l 
int yp » 35; 

if (mode = 3 |J mode = 7) 
yp “ 25; 

else if (mode > 3 it mode C 7) 
yp * 15; 

flet*y£get*0-10, gety 0 + yp); 
mode * 9; 

) 

1 

// - stationary sprites 


class Stander e public Pleyer [ 
publics 

Scantier () : Player ("skater .gfx") [ } 

1 , 

// -- the Scene: a skating pond 

class Pond : public SceneDirector C 

Standee *standerl; 

Stander 'stander?; 

Skater *skater; 
void on_tiper0; 
public: 

Pond(): 

~FondO: 

] i 

// - construct the scene 

Pond e : Pond f) ; SceneDi rector t" pond, pcx 11 } 

£ 

// — most distant stationary sprite 
stander1 ■ new Stander; 
s t ander1 _ ? set_imagena(10): 
standerl->eet3cy(1B0,100) e 
st ander1-> appes r 0; 

// — closest stationary sprite 
stander 2 = now Stander; 
stflnder2->set.i»ageno(9); 
etanderl-Jaeticy (140,130); 
stander?-?appear 0 e 

// - moving sprite 

skater ■ new Skater; 

J 

Fend: :Tond() 

E 

delate skater e 
delate atender?: 
delate SLander3; 

1 

// ---- called after each timer tick 
void Pond;;on-timer() 

£ 

Sc eneDirec tor:;on_time r 0; 

If (skater->steps == 0) £ 

switch {skater->modsJ £ 
case 1: 

//■— front lateral segment 
// set moving sprite in front of others 
KoveEToFrontfskater): 
break; 
case 3; 
case 7; 

// ™ center lateral segment 
// set moving sprite between other two 
ChangeZQrde r(skat c r,stande r 2) : 
break; 
case 5: 

// — rear Isteral segment 

// act Boving aptita behind others 

Gha ngeZflrde r { aka t ar f s t ande r 1); 

break e 
default; 
break e 

) 

) 

3 

int main{Int argc.char *argvl]) 

£ 

proceas,cmdlina{srgc H argv): 

Pond »pond = new Pond; // ncene director 
begin ("Pond"): // launch seen# 

delete pond: 
return 0; 

1 


End Listing 
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VFW & WING 


Video for Windows 
and WinG 


W liile Video for Windows (VfW) 
has been available for some¬ 
time, the only programming 
documentation for it is a help 
file supplied with die VfW de¬ 
velopers kit. This lack of information is 
unfortunate since VfW is remarkably in¬ 
teresting and offers numerous opportu¬ 
nities for creative programmers. 

For instance, writing a custom draw 
handler is a commonly used technique 
and is the basis of WinToon, the Microsoft 
cartoon engine, (WinToon is essentially a 
canned sprite playback engine for ani¬ 
mators, Walt Disney's Lion King soft¬ 
ware, for example, is a WinToon 
app.) In this article. I'll develop a 
custom draw handler and use tt in 
conjunction with Microsoft’s games 
interface, WinG, to scroll text across 
a video window. 

The Media Control Interface 

With the release of Windows 3.1, [Mi¬ 
crosoft made multimedia support a 
core part of the operating environ¬ 
ment, Windows 3*1 was initially 
geared toward w ave-form audio and 
Musical Instrument Digital Interface 
(MIDI) devices. Consequently, a cen¬ 
tral part of the architecture is the Me¬ 
dia Control Interface (MCI), which 


Chris is senior engineer at Symbionics 
Video Lid, f a technology development 
company that focuses on computer- 
video applications. He can he con¬ 
tacted at cpk@symbionics.CG.uk. 


Writing a custom 
draw handler 


Christopher Kelly 


provides a uniform method of accessing 
multimedia devices. 

From a programmer's perspective. MCI 
makes multimedia devices look like soft¬ 
ware VCRs, with commands such as play, 


pause, seek, and stop. The control of each 
MCI device is encapsulated in a driver 
called an “MCI command interpreter/' This 
design permits the addition of new com¬ 
mand interpreters as new- devices become 
available. 

The first version of MCI came with 
support for wave- form audio and MIDI 
devices. When VfW was released, it was 
shipped with its own command inter¬ 
preter. A later version of VfW, built on 
top of MCI, provided the preregistered 
window class, MClWnd, that supports 
video playback. MClWnd makes writing 
VfW applications a straightforward 
process, 

A Sample VfW Program 

As Listing One (page 22) shows, a 
video-playback program with con¬ 
siderable functionality can he writ¬ 
ten in less than 50 lines of code. 
Mast of the code, in fact, has noth¬ 
ing to do with VfW and is merely 
the minimum code required to write 
a Windows program. 

By using a modal dialog box, you 
avoid having to register a window 
class and create a message loop. An 
MClWnd child window is created 
to fill the client area of the dialog 
box. This window displays the 
video image and provides a num¬ 
ber of buttons for loading a video 
file and controlling its playback* 
You create the MClWnd window 
by calling the function MClWnd- 
Createf) in response to the WM_ 



Dr, Dobb’s Sourcebook , MaylJune 1995 


19 











VFW & WING 


IN1TDJAL0G message received by the di¬ 
alog box. This function is flexible and ac¬ 
cepts a number of flags that control win¬ 
dow attributes, such as whether it has a 
menu or slider control The MCh 
WNDFJMOTIFYSIZE flag requests the 
window to send notifications (using the 
MCIWNDM_NOTEFYSIZE message) to the 
dialog whenever the child window' 
changes size. The dialog box responds to 
this message by resizing itself precisely 
to enclose the child MCIWnd window 
within its client area. 

The final issue is handling palette 
changes brought about when the focus 
shifts between applications. In the dialog 
lx)x, you must respond to WMJPALETTE- 
CHANGED and WMjQUERYNEWPALETTE 
messages and route them to die MCIWnd 
window for processing. 

To build the program, you will need 
to get Lhe VfW developer kit, which is 
available, among other sources, from the 
Microsoft Developers Network level 2 
CD-ROM. Note that the program 1 devel¬ 
op here requires the vfw.h header file 
and die vfwdib library available from die 
MSDN. You also must include the mm- 
system.lib library, a standard part of the 
Windows SDK that should come with 
your compiler. 

This program is a fully functional play¬ 
back application. It displays a small win¬ 
dow' with a play/stop button, menu but¬ 
ton, and slider bar. The play/stop button 
is disabled until a video file is loaded. 
The menu button displays a pop-up 
menu, initially containing a single item 
for loading a video file. Once the file is 
loaded, the menu offers a variety of op¬ 
tions, including controlling the video size 
and the audio volume. There are a cou¬ 
ple of things you might like to try with 
these controls: 1. Hold down Ctrl while 
pressing the play button. Tills causes the 
video to play full screen, Be aware that 
not all display drivers support full¬ 
screen playback. 2. Hold the Shift key 
while pressing the play button. This 
plays the video backward, Although 
jerky, it does work. 

The program also w ill play other mul¬ 
timedia files such as wave-form (.WAV) 
files. 

What's Happening Under 
the Hood? 

The example program is deceptively sim¬ 
ple. Notice that the video appears to be 
playing in the background. This is because 
it is played under the control of a hidden 
program, MMTA3BCTSK, started by die MCI 
subsystem. MMTASK.TSK is a program de¬ 
spite not having an .EXE extension, 

Consider the sequence of actions MCI 
carries out to display die video in the way 
that we have seen: 


Some video codecs, 
known as “rendering 
drivers ,” are capable 
of sending data 
directly to the display 


1. Read the compressed video and audio 
data from the file. 

2. Decompress the video. 

3. Decompress the audio, 

4. Send the decompressed video data to 
the display hardware, 

5. Send the decompressed audio data to 
the audio hardware. 

The video and its associated audio are 
stored on disk in audio video interleaved 
(AVI) format, a special case of the Re¬ 
source Interchange File Format (RIFF). 
(For a discussion of RIFF, see M Inside 
the RIFF Specification," by Hamish Hub- 
hard, DDj, September 1994.) Conceptu¬ 
ally, an AVI file appears as a number of 
streams of data. For example, one 
stream will contain the video and an¬ 
other the audio. For performance rea¬ 
sons, the video and audio frames are in¬ 
terleaved in the File on a frame-by-frame 
basis. MCI reads the streams using a 
VfW subsystem called AVI File, which 
provides a rich set of functions for read¬ 
ing and writing AVI files. 

At this point, the audio and video are 
still compressed and must be decom¬ 
pressed before rendering, VfW has two 
subsystems that handle this task. The in¬ 
stallable compression manager (1CM) han¬ 
dles video, and the audio compression 
manager (ACM) liandles audio. These two 
subsystems have a lot in common: Each 
uses a driver architecture in which the 
task of decompressing the data is dele¬ 
gated to DLLs known as “codecs. rt Once 
decompressed, the video and audio can 
he sent to the display and audio hard¬ 
ware. At this point, tire video frame is a 
device independent bitmap (DIB) and is 
displayed using a high-performance bit- 
bit function in the DrawDib subsystem. 
When VfW is installed or the display- 
driver mode is changed, DrawDib pro¬ 
files the various methods of performing 
a bitbit and selects the quickest. The lat¬ 
est release of VfW (Version l.ld) will use 
the display control interface (DCI) for ac¬ 


cessing the frame buffer directly as long 
as a DCI provider is present. 

That explanation gives a somewhat sim¬ 
plified view of what actually happens. 
Some video codecs, known as “rendering 
drivers," are capable of sending data di¬ 
rectly to the display. They may even make 
use of video hardware for part of the de¬ 
compression process, such as color-space 
conversion or scaling. The relationship 
between the ICM and DrawDib is quite 
tight. DrawDib wall accept compressed 
video data and automatically send it to 
the ICM for decompression. The binding 
between the ACM and the Windows 
sound subsystem is equally tight. A com¬ 
ponent called the u wave-form mapper" 
intercepts any compressed audio data sent 
to the sound subsystem and routes it to 
the ACM for decompression, 

A More Complicated VfW 
Program 

The next example is similar to the last, 
except it scrolls the text Hello World” 
across the video window-. This effect is 
achieved by adding a custom draw han¬ 
dler to intercept the DIB just before it 
is displayed on the screen. 11 then 
draws the text into the DIB before ren¬ 
dering it using DrawDib Tills illustrates 
a general technique that can be used 
for a variety of effects. For example, it 
is the method used by Michael Windser 
to implement WinToom Like WinToon, 
this example uses WinG for drawing on 
the DIB, 

Before going further, it is necessary to 
define a custom draw handler. To do that, 
we must take a further step back and ex- 
piain what an installable driver is. 

Installable Drivers and 
Draw Handlers 

An installable driver is a DLL that has a 
particular entry point that must be called 
DriverProcf. X The driver is registered with 
Window's using the Drivers applet in the 
control panel If you start this applet, you 
can see the list of installable drivers pre¬ 
sent on your machine. Several compo¬ 
nents already mentioned-—the audio and 
video codecs, the wave-form mapper, and 
the MCI command interpreters—are in¬ 
stallable drivers, Windows uses the Drwer- 
Pfoc to send messages to a driver in much 
the same way that it calls a window' pro¬ 
cedure to send messages to a window, 
although the set of messages is completely 
different. 

The DriverProc has the following pa¬ 
rameters: 

* driverlD is a driver-supplied value that 

the driver passes hack to Windows 

when the driver is opened. This value 

is then passed to the driver on all sub- 
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sequent calls to DriverProc. 

• gDriver Ls a unique value assigned by 
Windows to identify the driver. 

• msg identifies the message. 

• lParaml and lParam2 are 32-bit values, 
the meaning of which depends on the 
value of msg. 

The messages can be divided into stan¬ 
dard messages and driver-type-specific 
messages. Standard messages are sent to 
all installable drivers, whereas type- 
specific messages are sent only to drivers 
of a particular type. For example, a de¬ 
fined set of type-specific messages is sent 
to all video codecs. 

A draw handler is similar to the 
DriverProc of an installable driver in that 
it must have the same prototype, and it 
receives the same messages. A draw 
handler does not, however, need to be 
named DriverProc. 

What is WinG? 

Microsoft is anxious to make Windows a 
good platform for games. In support of 
this initiative, Microsoft has developed 
WinG, die games-programming interface, 
which was released late last year. A tech¬ 
nique commonly used by games writers 
is to compose an image in an off-screen 
buffer before copying it to the display. 
This composition may involve using stan¬ 
dard drawing primitives or, for some op¬ 
erations, direct manipulation of the bits 
of the image. Using both drawing prim¬ 
itives and direct manipulation is difficult 
in Windows because the bitmaps used 
by the graphic device interface (GDI) 
graphics engine are device dependent. 
WinG solves this problem by providing 
specialized device contexts and bitmaps. 
You can draw into a WinG bitmap using 
the standard GDI drawing primitives or 
directly manipulate it as a DIB. In the 
next example, 111 use both of these ac¬ 
cess methods. 

In at the Deep End 

The “Hello World” example program in List¬ 
ing Two (page 22) is based on the first ex¬ 
ample with the addition of a draw handler. 

Since WinG can only cope with 256- 
color palletized displays, this program 
must be run in a 256-color display mode. 
You should call the function Is256Color- 
DisplayC) in WinMainC), which perfonns 
the necessary check to ensure this is the 
case. Most of the remaining code you 
need to write deals with the draw han¬ 
dler together with the functions that it 
calls to process messages. A word of 
warning about the prolog code for the 
draw handler: Because it is called from 
within the context of MMTASK.TSK, smart 
callbacks will not work. You must call 
MakeProclnstanceC) to generate the code 


Microsoft is anxious 
to make Windows a 
good platform 
for games 


to correctly load the data segment on en¬ 
try. This type of application is one of the 
few places where it Ls still necessary to 
use instance thunks in Windows pro¬ 
gramming. 

You pass the MCIWNDF_NOTIFY- 
MEDIA flag to MCIWndCreate( ), re¬ 
questing the MCIWnd window to send 
notificatioas (MCIWNDM_NOTIFYMEDIA) 
to die dialog whenever a new file Ls load¬ 
ed. Install your draw handler in respoase 
to this message. 

Many of the messages that your draw 
handler receives require little or no pro¬ 
cessing. In Listing Two, these messages 
are grouped together for convenience at 
die beginning of the draw handler. 

The first message that your draw han¬ 
dler will receive is DRV_OPEN, and in 
response, you should allocate a data 
structure of type Drawlnfo. This will be 
used to store information required for 
processing later messages. The address 
of this data structure should be returned 
from the draw handler and it will be 
passed as the driverld parameter of sub¬ 
sequent messages. In C++, structures can 
have methods as well as data members. 
For Drawlnfo , diis convenience allows 
you to write methods to handle each of 
the messages received by the draw han¬ 
dler. The constructor for the Drawlnfo 
structure should allocate the WinG de¬ 
vice context that will be used for draw¬ 
ing and also call DrawDibOpen() to reg¬ 
ister with DrawDib. The destructor for 
DrawDib must release any resources ac¬ 
quired by the draw handler and also 
deregister with DrawDib. 

The next message you get is the ICM_ 
DRAW_SUGGESTFORMAT, asking which 
DIB formats you are prepared to accept. 
The proper response is, “8-bit-per-pixel 
uncompressed DIBs.” VfW will attempt 
to find a codec that will convert the DIB 
to this format before passing it to you. 

Before asking your draw handler to 
draw any DIBs, Windows will send the 
ICM_DRAW_BEGIN message, allowing 
you to perform any necessary prepara¬ 
tion. There are several tilings you must 
then do. The DrawDib subsystem must 


be prepared by calling the function 
DrawDibBeginf), and you must call 
WinGCreateBitmapO to create a WinG 
bitmap, which will be used for drawing 
the text onto the DIB. This also is the 
point where you should store the source 
and destination rectangles in the Draw¬ 
lnfo structure. The ICM_DRAW_BEGIN 
message may be sent to you several 
times, and you should prevent resource 
leakage by deleting any WinG bitmap 
that you may have allocated in an earli¬ 
er call. 

Before you can draw any DIBs, the 
palette must be initialized correctly. You 
will receive the ICM_DRAW_REALIZE 
message asking you to realize the palette. 
You should call DrawDibRealize to do 
thLs for you. 

And now to the main work of draw 
handler: You will be sent the ICM_DRAW 
message whenever you must render a 
DIB. For this, you should compose the 
DIB to be displayed in the WinG bitmap, 
then call DrawDibDraw() to display it. 
To compose the DIB, you should first 
copy the DIB you are given into the WinG 
bitmap, then use the GDI function Text- 
Out() to write the text on top. In the ex¬ 
ample, the code to compose the DIB is 
confined into the method Compose - 
Framef), making it easy for you to mod¬ 
ify the composition and devise your own 
interesting effects. 

Your draw handler must handle any 
palette change requests that may occur. 
Call DrawDibChangePalette to do thLs. 

Finally, some advice on how to build 
the example application: You will need 
the VfW and WinG developer kits, which 
are lx)th on the Microsoft Developers Net¬ 
work Level 2 and Multimedia Jumpstart 
2.0 CD-ROMs. In addition, the WinG de¬ 
veloper kit Ls available on the Internet 
from Microsoft’s FTP site (ftp.micro- 
soft.com) and in the Windows Multimedia 
forum on CompuServe (GO WINMM). 

If the example works but displays 
garbage text rather than “Hello World,” 
then you are probably using smart call¬ 
backs. See your compiler documentation 
for information on how to turn these off. 

Where to Go from Here 

For more information about VfW, you 
should refer to the help file that comes 
with it. At first sight, this can be some¬ 
what intimidating because there is no ar¬ 
chitectural overview. However, the effort 
Ls worthwhile, since there is a wealth of 
information hidden within. It is also worth 
spending some time examining the sam¬ 
ple applications that come with the VfW 
developer kit. 

DDJ 

(Listings begin on page 22.) 
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VFW & WING 


Listing One (Texi begins on page 19.) 

tide fine STRICT 
ftinclude iwindovs,h> 
ttinrluda Catting.h> 
ft include <vfw + h> 

static HTN5TANCE hlnatanceG = 0; // Pats instance handle, 

static HWND hHGIWndG M ; // Handle of the MCI display window. 

// Function prototypes 

static void ResizeWinde^rQFit{HWMD hWhd): 

// Make DIgProc extern w C r to prevent C++ name mangling, 
extern "C" 

BOOL CALLBACK DlgProc(HWND hWnd, UINT msg. WPARAK wParsm. LPARAM lFaramh 
int PASCAL WinHain (HINSTANCE Mnstance, HINSTANCE hPrevInst, LPSTR pCMLitie, 


return DialogBex{hlnetenceG = hlnetfmce. N AVlSBE h .fl,DlgProc): 

3 


Listing Two 

hdefine STRICT 
HInclude twlndowa.h> 

Ninclude <windowsx.h> 
ftinclude {string.h* 

«include <vfy.h> 
ft include <ffljnByEtein.h> 
riinclude <digitaiv,h> 
ftinclude <mciavi,h> 
fttociude Cwing.h> 

// Global Variables 

static HINSTANCE hlnstanceC = 0: // Data instance handle, 

static HVNP hMClWndG = 0 : // Handle of the MCI display wind ec¬ 

static FARFROC pDraw3IajidlerThunkG*0; // Instance thunk for draw handler 

// Private data structure used for storing drawing information. 

// This is C++ so it can have sethoda, 
struct Drawlnfo 


U Dialog Procedure 

BOOL CALLBACK DlgFrocfHWND hWnd. UINT Mg, VFAFjVM wPeran. LPARAM iPsran) 

t 

switch{mag) 

t 

case WM-INTTDIALQG: 

hMClWndG = MCIWndCreata{hWnd h hInstanceC. 

W5_CHILD 1 W3_VISIRLE ! MCTVMJF-NOTIFYSIEE,0); 
fteeizaWindpwToFit EhWiid) i 
return TRUE: 
taga WM_CLOSE; 

EndDlalog{hWnd,0): 
return TRUE: 
case WH_PALETTECHANGED: 
rase WM^QUERYMEWPAUm ; 

SendMe s sage fhMGIWndG.msg,wPar am r lFaram); 

return TRUE: 

case KC1WNDK-N0TIFYSIZE: 

Reei?eWindowd , oFit{bWnd): 
return TRUE; 

3 

return FALSEi 

\ 

static void ResifceWinddtfToFit (DVND hWnd) 

t 

RECT rect: 

GotWindowRoet thNCttfodC. 6-reot); 

AdjuaLWiodowRect{fitact.GetWindowLDng{hWnd,OWL.STYLE).FALSE); 
SetWindowPos (hWnd,0.0,0, rect, right-reel. left, reot, bottom-reel .top r 
SUP_HOMOYE | SWP.HOEOBDER); 

3 


ft Methods 

DrawlnfoO: 

""Drawlnfo (): 

LRESULT Begin{ICDRAWBBGIN PAR * P Hegin): 

LRESULT Drav(ICDRAW FAR *pDrawStruct)f 
LRESULT End{) : 

LRESULT ChangePaletie(LFBITNAPIMFOHEAEER plnfoHeader)f 
LRESULT GetPa 1 ett e £.): 

LRESULT Realise(EDC hDC. BOOL background); 

FOOL C&nHandleFormat(LFETTNAPIWFQHEADKR plnfoHeader)| 

void CornpoaeFrame (LPBITMAPINFQHEADER plnfoHaadet. LPVQIB plmageBits) 

LRESULT SuggestForrat{TCDRAWSUGGEST FAR ^Suggest); 

/f Data membera 


LFTOID 

pBuffer-; 



HDRAWDIP 

hDD^t 



HDG 

hDC.; 



HDG 

hWinfiflC.: 



RBITKAP 

hWinGBitmap.: 



HE1TKAP 

hOldBitmap-i 



int 

xDflt.: 

It 

Deatinaticm rectangle 

int 

yDst_: 


int 

dxDst,: 



int 

dyDst_: 

it 


int 

xSrc.; 

Source rectangle 

int 

ySrc_: 



int 

dxStc.; 



int 

dySrc_; 

it 


char 

eCaptior: [32 3; 

Text to write 

int 

captionX_; 

it 

Current position of 

int 

ceptionY.: 

it 

the text on the window. 

int 

windo-wWidth.; 

it 

Width of the video window. 





S *._, 

, N 8> 

shsl - . •* - o - ~ ~ ~. 


^ ^ ** *-^ ^ ** - ^ 4 

_ - 

Programmer's Graphics library 




Ftrtfgraph rM 4.0 sett the slBinbrd For OUS proltcted mode graphics programming. 

Uic His [ompiler and DOS estender af your thoite la create high-powered fast action 
ffimiBv. Direct hortfwnre support Foi nil popular SVGA thipwitt. tour applications will 
soar lo new heights with FoitgropM 

Ted Gruber Software • P,0 + Bo* 1340B * Las Vegas, NV £9112 j 
Orders only: 1'£00 410-0192 Fax: (702) 735-4603 

information: [702) 735-1930 BBS: (702) 796-7134 

Call Fen n free deme dhh dr download on evaluation kit from our Ml loday. 


) : 

// Function prototyp^o 

// Make exported functlana extern '‘C' r to prevent C++ name mangling, 
extern ” C IP 
t 

BOOL CALLBACK DlgPrm(HWMD hitad. UINT nsg F WPARAM wParam, LPARAM Ifaram); 
LRESULT CALLBACK iWHandler(DWORD id. HDRVR hDriver. UINT MSG. 

LPARAM IParaml. LPARAM lParam2): 

) 

static void Re sizeWindswToFit(HWND hWnd)j 

static void CopySyflternPalette(LFRGBQUAJ) pColors): 

static BOOL I«256ColorDiaplayO: 

static BOOL InstallDrawHandler(HWND hMCIWnd); 

static LRESULT HatidleDtiverCpen (1 COPEN FAR *pOp); 

static LRESlfLT Rand leD river Cl sea {Drawlnfo •pbrsv): 

int PASCAL WinMain(RINSTANCE hlnatance, HTNSTANCE hPravInst. 

LPSTR pCmdLine. int cmdShow) 

( 

if (iNlbSColarUiaplayO) 

DifllogBox(hInstanceG = hi net ana e, Ir AVI SEE" ,0.DlgProc3 7 
else 

Mr-sfirtgcRoxtE. "TTiiff program requires a 256 color dlaplay". "AVISEE" .MFL0K) s 
return 0i 


// Dialog Procedure 

MOL CALLBACK BlgProc(KWND hWnd. UINT tnsg. WPARAM wParam. LPARAM IParam) 

t 

switch {wag) 

t 

caire WH_iMtTtHALOG; 

H Create the video window, 

hMClWndC = NCI WndC rest e(hWnd.WnstBriceG. 

WS..CHILD ] WS-VISIBLE 3 MCIWMDF.NOTIFYSIZE 
! HGIWNDF-NUTtFYMEDlA.0)i 
Re aIzeWindoWTaFIt[hWnd )j 
return TRUE: 

case UK_CL0flK-: 

EndMalog(hWnd.0): 
tetum TRUE; 
case UM_PALETTECHANGED: 
case WM-QUERYNEWPALETPE: 

// Pass on palette measagep. 

SendMeagage(HMCIWndC.bag,wParam,IParam): 
return TRUE; 

case HCIWJMT_N0TIFYSm: 

ResizeWindowToFit(hWnd ); 
return TRUE: 

case MCIWNDM.NOTIFYMEDLA: 

InstallDrawHandleri[HWND)w?sram): 
return TRUE: 

) 

return FALSE: 

1 

static void ReEizeWindowToFit(HWND LWnd) 

l 


CIRCLE NO. 2 ON READER SERVICE CARD 


RECT recti 

GetWindowRect(hMCXVndG,fcrect); 
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AdjustWindowRect(6rect,GetWindowLong(hWnd,GWL.STYLE).FALSE): 
SetWindowPos(hWnd.0.0.0,rect.right-rect.left.rect.bottom-rect.top. 
SWP.NOMOVE I SWP.NOZORDER); 

) 

static void CopySystemPalette(LPRGBQUAD pColors) 

C 

PALETTEENTRY aPal[256]; 

HDC hDC = GetDC(0); 

GetSystemPaletteEntries(hDC.0.256,aPal); 

// Unfortuanately RGBQUAD and PALETTEENTRY have the colors in the 
// opposite order so we have to copy then one by one. 
for(int i=0; i<256: i++) 

( 

pColors[i].rgbRed = aPal(i].peRed: 

pColors[i].rgbGreen = aPal[ij.peCreen; 

pColorsiij.rgbBlue » aPal|i].peBlue; 

pColors[ij.rgbReaerved = 0; 

ReleaseDC(0,hDC): 

) 

static BOOL Is256ColorDisplay() 

( 

BOOL ok = TRUE: 

HDC hDC ■ GetDC(0): // Get DC for desktop window. 

// Check it is a palettized display, 
if(GetDeviceCaps(hDC.RASTERCAPS) 6 RC.PALETTE**®) 
ok = FALSE: 

// Check it is 256 colors (8 bits per pixel), 
if(GetDeviceCaps(hDC.BITSPIXEL)‘GetDeviceCaps(hDC.PLANES)!=8) 
ok « FALSE: 

ReleaseDC(0,hDC); 
return ok: 

} 

static BOOL InstallDrawilandler (HVND hMCIVnd) 

{ 

BOOL ok « TRUE: 

MCI_DGV_SETVIDEO_PARKS parms: 


// We may be called before we MCIVndCreste has returned and so the 
// MCI window handler will not have been assigned to hMCIVndG. 
if(IhMCtWndG) 
hMCIWndG - hMCIWnd; 

// If we haven't create the instance thunk then do so. 
if (IpDrawHandlerThunkG) 

pDravHandlerThunkG * KakeProcInstance((FARPROC)DrawHandler.hlnstanceG): 
parms.dwValue * (DWORD)pDravHandlerThunkG: 
parms.dwltem - MCI_AVI_SETVIDEO_DRAW_PROCEDURE; 


// MCIWnd does not provide a function for installing a draw handler 
// so we get the MCI device ID and set it the HCI.SETVIDEO window. 
UINT devicelD * MCIWndGetDevicelD(hMCIWndG): 
if(devicelD) 

( 

meiSendCommand(devicelD.MCI_SKTVIDEO. 

MCI.DGV.SETVIDEO.ITEM I MCI.DGV.SETVIDEO.VALUE, 

(DWORD) (MCI.DGV.SETVIDEO.PARMS FAR*)6parms); 

) 

return ok; 

) 

// The Draw Handler 

LRESULT CALLBACK export DrawHandler(DWORD id. HDRVR hDriver. UINT mag. 
LPARAM lParaml. LPARAM lParam2) 


C 


Drawlnfo *pDraw = (DrawInfo*)id: 
switch (msg) 

[ 

// Many of the driver messages require no processing so we 

// will get the* out of the way first. 

case DRV.LOAD: 

case DRV.FREE: 

case DRV DISABLE: 

case DRV.ENABLE: 

case DRV.INSTALL: 

case DRV.RKMOVF,: 

case DRV.CONFIGURE: 

return 1; 

case DRV.QUERYCONFICURE: 
case ICK.GETSTATE: 
case ICM.SETSTATE: 
return 0: 

case ICM.CONFIGURE: 

case ICM.ABOUT: 

return ICERR.UNSUPPORTED; 

// Open and close we need to handle - this is where we allocate 
// and free our private data structure, 
case DRV.OPEN: 

return (lParam2) ? HandleDriverOpen((ICOPEN FAR *)lParara2):1; 
case DRV.CLOSE: 

return HandleDriverClose(pDraw): 

// Code for drawing, 
case ICM.DRAW.BEGIN: 

return pDraw 7 pDraw->Begin((ICDRAWBEGIN FAR *)lParaml) 

: ICERR.UNSUPPORTED; 
case ICM.DRAW: 

return pDraw 7 pDraw->Draw((ICDRAW FAR •)lPararal) : ICERR.UNSUPPORTED: 
case ICM.DRAW.END: 

return pDraw 7 pDraw->End() : ICERR.UNSUPPORTED : 

case ICM.GETINFO: 

return ICERR.UNSUPPORTED: 

case ICM.DRAW.QUERY: 

return (pDraw 66 pDraw->CanHandleFormat((LPBITMAPINFOHEADER)lPararal)) 

? ICERR.OK : ICERR.BADFORMAT; 
case ICM.DRAW.SUGGESTFORMAT: 

return pDraw ? pDraw->SuggestFormat{(ICDRAWSUGGEST FAR *)lParaml) 

: ICERR.UNSUPPORTED: 
case ICM.DRAW.REALIZE: 

return pDraw 7 pDraw->Realize((HDC)lParaml.(B00L)lParam2) 

: ICERR.UNSUPPORTED: 
case ICM.DRAW.GET.PALETTE: 

return pDraw ? pDrav->GetPalette() : ICERR.UNSUPPORTED: 
case ICM.DRAW.CHANGEPALETTE: 


return pDraw 7 pDraw->ChangePalette{(LPBITMAPINFOHEADER)lParaml) 

: ICERR.UNSUPPORTED: 

) 

if (msg < DRV.USER) 

// Send all other standard installable driver messages for 
// default processing. 

return DefDriverProc(id.hDriver.msg.lParaml,lParam2); 
else 

// Anything else we don't support 
return ICERR.UNSUPPORTED: 

1 

static LRESULT HandleDriverOpen(ICOPEN FAR *pOpen) 

( 

LRESULT retVal = 0L: 
if(pOpen) 

( 

// We only accept video streams and we do not 
// handle compression and decompression, 
if (pOpen->fccType ■■ streamtypeVIDEO 66 
pOpen->dvFlags != ICMODE.COMPRESS 66 
pOpen->dwFlags !* ICMODE.DECOMPRESS) 

( 

// Allocate a private structure for storing information. 

Drawlnfo *pDraw * new Drawlnfo; 
if(pDraw) 

( 

pOpen->dwError = ICERR.OK: 

retVal = (LRESULT)(Drawlnfo FAR *)pDraw: 

) 

else 

pOpen->dwError = ICERR.MEMORY: 

) 

) 

return retVal; 

) 

static LRESULT HandleDriverClose(Drawlnfo *pDraw) 

( 

delete pDraw: // Destructor tidys up. 
return 1: 

) 

// Methods for class Drawlnfo 
Drawlnfo::DrawInfo(): 
pBuffer.(0). 
captionX (0). 
captionY.(0). 
hWinGDC. (0). 
hWinGBitmap.(0) 

( 

hDD. = DrawDibOpen(); 
hWinGDC. * WinCCreatcDCf); 
wsprintf(aCaption.,"Hello world"): 

J 

Drawlnfo::~DrawInfo() 

( 

// Pree any resources we still have, 
if(hDD.) 

DravDibClose(hDD_); 
if(hWinGDC. 66 hWinGBitmap.) 

DeleteObject(SelectObject(hWinGDC..(HGDIOBJ)hOldBitmap.)); 
if(hWinGDC.) 

DoleteDC(hWinGDC.): 

) 

LRESULT Drawlnfo::Begin(ICDRAWBEGIN FAR *pBegin) 

C 

struct 

f 

BITMAPINFOHEADER infoHeader: 

RGBQUAD coiorTable[2561: 

) infoHeader: 

if(CanHandleFormat(pBegin->lpbi)) 

( 

// We may be called several times without a corresponding call to 
// several times so roust delete the WinG bitmap if it already exists, 
if(hWinGBitmap.) 

[ 

DeleteObject(SelectObject(hWinGDC..(HGDIOBJ)hOldBitmap.)): 
hWinGBitmap. =0: 

DrawDibEnd(hDD.); 

} 

hDC. * pBegin->hdc; 

xDst. * pBegin->xDst: yDst. = pBegin->yDst: 
dxDst. * pBegin->dxDst: dyDat. = pBegin->dyDst; 
xSrc. * pBegin->xSrc: ySrc. = pBegin->ySrc: 
dxSrc. = pBegin->dxSrc: dySrc. = pBegin->dySrc: 
captionY. = pBegin->dyDst/2; 
windowWidth. = pBegin->dxDst; 

SetStretchBltMode(hDC.,COLORONCOLOR): 

if (DrawDibBegin(hDD_.hDC..dxDst..dyDst..pBegin->lpbi.dxSrc_.dySrc.,0)) 

( 

hmemepy(6infoHeader.pBegin->lpbi.sizeof(BITMAPINFOHEADER)); 

// Get the system palette entries. 

CopySystemPalette(infoHeader.coiorTable); 

// Create the WinG bitmap. 
hWinGBitmap. = 

WinGCreateBitmap(hWinGDC..(LPBITMAPINFO)6infoHeader,6pBuffer.): 
if(hWinGBitmap. 66 pBuffer.) 

( 

// Select the WinG bitmap into the WinG device context. 
hOldBitmap. ■ 

(HBITMAP)SelectObject(hWinGDC..(HGDIOBJ)hWinGBitmap.); 
return ICERR.OK: 

) 

else 

return ICERR.MEMORY: 

) 

else 


(continued on page 24) 
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/* < CapcomN/ 



?OFTWARE 

ENGINEERS 

Get in on the Game 

[q 

1_1 

IO 


They’ve told you 
all 

Along that 
Work is Work and 
Play is Play... 
f It doesn't have to be That) 
Way! 


If you want to combine the Of 
two, write Software, and 
play Arcade Games, 

We want to talk to you! 


Capcom, designer and manufacturer of coin- 
operated electronic games, is in search of ambi¬ 
tious and skilled full-time software engineers for 
pinball. You must be proficient in 68000 
Assembly and C. 


Excellent benefits/competitive salary. Mail or 
FAX resume and cover letter, Code Samples and 
Salary Requirements to: 

Human Resources 

Capcom 

3311 N. Kennicott Avenue 
Arlington Heights, 1L 60004 
FAX: 708-797-6228 
No Phone Calls Accepted 
EQE 

We Want You To Do What Most Software 
Engineers Only Dream Of Doing! 


Listing Two (Listing continued , text begins on page 19 ) 

return IGERR.UH&UPFGRTED; 

3 

ela* 

return ICEKR.MDFOEMAT: 

) 

UiESULT Drawlnfa::DrawflCORAV FAR fpDravStruct1 

t 

HINT wFlage: 
wFlags 3 DDF_SAME_HDC; 

if UpDraw5truct->dwFlage h I CDtoW.iTULLFRAME) | \ 
pDr av/Ft ruct- > lpDat a ■■ MULL) 
t 

if(pDrawStruc t-> dvFlaga & ICDRAW, UPDATE) 
vFlags != PDF-UPDATE; 

else 

return ICEBBJGKi 

3 

if (pDrawRtruet-MwFlags t. ICORAU-PRIROU.) 

wFlaga i- DDFJX3WTDRAW; 

if {pD r avSt rue t - > dvFl a ge & 1 CURAtf-HURJRYUF) 

wFlaga !■ DDFJHJRRYUF; 

ft Compose the DIB in the WinG bitmap. 

ConpoSeFranie ((LFBITMAPIHFGHEADEE,) pDrawStruct-JlpFormat f pDrawStruct->lpData) ; 
// Fit the VinG bitmap to the screen, 
if fIDrawDibDrawChDEL ,hDC., xD et, yDat _ . dxDst _ , dyDat _ , 

(LPfiITMAPINFQKEADER)p DrawS t rue t->1pFo rmat, 
pBuffeEV .jtSrc-, ySrc- H dxSrc_ f dySrc_.wFlags)) 

t 

if (yFlaga & DDF_UPDATE) 

return ICERR_CAHTUPDATE; 

else 

return ICERR_UNSUPPORTED; 

3 

return 1CERR.0K; 

3 

void Drawlnfo::CompofleFrflmefLFBIlHAFrMFOHEADER plnFoHeader. LPV03U plmageBits) 

iffpBuffer.) 

E 

ft Copy the bitmap we are given into the WinG bitmap, 
hmemc py(pBuf fe r _,pl msgeFit s,pInfoHeade r-> biSiie l mage}: 

SetBkHode(KWinCDC..TRANSPARENT); 

SetTextColor(hVinGDC-,RGB(2 55,0,0)); 

// Dtaw ‘Hello World’ an tap. 

TentQut (hWinGDC. ,captionX_ .captionY., ,aCaption_ ,lfltrlen{aCaption_)); 

// Update the position to draw the text - cetLeea ecrolllng- 
captlonX. = fcaptlunX_+UliwiiidowWldtli_; 

1 

1 

LRESULT Drawltifq: ;Eod f) 


C 


return fCKBF.OK: 


IRESULT Drawlnfa::fljfetP*]ette( ) 


) 


return (UtHSULT) t!ttMT) DrawlHbGetF&lettefhDD.); 


LKESULT Drawlnfo::ChangeFalettc(LPBrTMAFINFUHEADER plnfoHeader) 

t 

FALETTEENTRY aPaiet te12 56 J; 

LPRGBGUAD pCalora = (LPRGBQUAD) (ILPRYTEJ plnfaHeeder + plnfoHeader^MSize) ; 

// That annoying RGB ordering problem again. 

for lint i=0; i<{int)plnfoHeader->biClrUaed: i++) 

E 

aFalettefi|.peRed - pCalora[i].rgbRedS 
aPaletteii!,peGreen ■ pColorsTi).rgbGrten: 
aPalette [i [, peBlue = pColore U ] ► rgbBllle 1 
aPalottoEi].pc Flags; ” 0; 

1 

DrawDibChangeFalette[hDD. r 0,(int)pInfoHfiader->biCltUaed,aPalette): 
ruturn ICEKILQK; 

J 

LRESULT Drawlnfo;:Realise(HDC hDC, BOOL background) 

E 

hUC_ = hDC: 

return (hDC. && hDDj ? DtawDihRealiKediDD,. hDC_ t back ground) 

: ICERF-UNSUPPORTED; 

) 

BOOL Draw Info ? i CsnHandl eFo rut {LPBTrMAFlHFUEEADER plnfoHeader) 

f 

return (pTnfoHeader t*b plnfoKeadtr^biConprcseicn ■■ BI.RGB 66 
(pInfoHeader->biPlane a*plnfaHeadet h iBitCaunt-^)) 

? TRUE i FALSE; 

} 

LRESULT Drawlnfo::SuggestFormat(TCDRAWSUGGEST FAR *pSu s geet) 

E 

if (pSuggeat’>lphiSuggeer: ■■ NULL) 

return a tseof (BITWINFOHFADFF) + 556 ■ size of fRGBQUAD): 

//We only want 0 bita-per-pixel uncompresaed RGB DIBa. 
pSuggeBt->lpblSuggest->biGompreiBion = BI_RGB: 
pSuggeflt-JlpbiSug 4 est*>biPlanes ■ Is 
pSugseat->lpbiSuggest->biBitCount = &; 
return aiieof{BI'niAPTNFOHEADER) + 

pSugEest->lpbiSuggeBt-5biClrUsed * aizeof(RGBQUAD); 

J 


End Listings 
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SOUND 


Music and Sound for 
Interactive Games 


usic and sound effects are the 
:: most powerful tools available tor 
t you to emotionally impact users, 
Without them, users don’t know 
: how to “feel.” Music and sound 

help users understand context in your soft¬ 
ware. The shower scene in Psycho would 
be meaningless without the accompany¬ 
ing music. How would you know when 
to be scared in a horror film? On die edge 
of your seat in a suspense movie? Near 
tears at the end of Old Yeller? What would 
make you leap out of your seat scream¬ 
ing as a dinosaur rips through a Land Rover 
or an alien monster comes tearing down 
a hallway without the accompanying 
sound and music? 

While we know this intuitively, you can 
still test this for yourself in a literal fash¬ 
ion. Rent a videotape of Terminator 
II , Conan the Barbarian , Star 113m; 
Aliens, or Jurassic Park Every time 
you hear your heart racing during 
die film, close your eyes and think 
very hard about what you are hear¬ 
ing. Listen to how the primary 
melody of the film s music score is 
interwoven and allowed to build and 
evolve during different portions of 
the film. During a really bud action 
sequence, turn the volume off. You 
will feel the tension of the situation 
vanish as if you had dosed the spig¬ 
ot to a faucet of rushing water. 

Notliing is done with sound and 


John is a graphic artist, designer and 
programmer whose credits include 
computer games such as 688 Attack 
Sub and SSN-21 Sea wolf from Elec¬ 
tronic Arts . You can contact him on 
CornpuSetve at 702533237 or on bis 
BBS at 314-939-0200. 


Enhancing the 
power of your 
software 


John W. Ratcliff 


music in film that we w ould not want to 
emulate with software—with one ex¬ 
ception. In computer games, we want the 
sound effects, dialogue, foley. and music 
to lie both interactive and contextual to 
die environment By adding interactive el¬ 
ements to the soundtrack, the emotional 



content becomes magnified. A sound track 
has four major components r dialogue, 
sound effects, foley, and music. Let's take 
a brief look at each and examine how you 
should apply diem to your game. 

■ Dialogue. Most of die dialogue you 
hear in movies has been redone in a stu¬ 
dio after the scene w'as shot. This allows 
actors to focus on how they sound and 
lets the sound designer control the exact 
balance of the audio in the finished sound 
track. Clearly, it is important that all of 
your dialogue be done professionally in 
a recording studio. How ever, unless you 
have been given a huge budget, you protv 
ably can’t afford Hollywood actors and an 
expensive studio, The alternative is sound 
engineers who offer full audio services. 
These professionals not only pro¬ 
vide you w ith composing services 
but also provide voice actors, cus¬ 
tom digital sound effects, and mix¬ 
ing, They can even deliver the au¬ 
dio in computer-data format at the 
resolution you need, customized for 
the various hardware platforms. 

■ Sound effects. While many sound- 
effects libraries are available, some 
games call for custom effects. Com¬ 
mon sense suggests you use clip 
sound libraries where you can, but 
go to a professional sound engineer 
to get effects that exactly match the 
content of your game. 

* Foley. Foley effects are ambi¬ 
ent, supporting sound effects that 
you don’t even notice when you 
watch a film—but you would no¬ 
tice them if they weren’t there. Fo¬ 
ley effects include footsteps, cars, 
wind, birds, or any other environ¬ 
mental sounds that support tire con- 
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tent. In Hollywood every single footstep 
and rustle of fabric is added to the sound 
track and synchronized frame by frame to 
the film as a post-production process. Fo¬ 
ley effects create a greater sense of “vir¬ 
tual reality* tlian die most exacting com¬ 
puter graphics. They are greatly enhanced 
if used with special processing like 
Qsound, reverb, and other digital-signal 
processing effects. Reverb is a technique 
where sounds are fed through a signal¬ 
processing phase to approximate the echo 
and reflections found in a real environ¬ 
ment. For example, on the Creative Labs 
AWE32 sound card you can program the 
exact characteristics of the shape of a 
room through MIDI events. Instantly, all 
foley effects will sound as though there 
were occurring in a room of that shape 
and size, 

Foley and digital sound effects are die 
most highly interactive tools you can ap¬ 
ply to your sound track. With foley, you 
let the user hear footsteps, gunshots, 
growls of a monster around a comer, wind 
blowing, birds chirping, and street noise. 
As long as these sounds are in real time, 
contextual to where they are in your vir¬ 


tual reality, they will draw the user very 
deeply into the world you have created. 
This magnification of the virtual-reality ex¬ 
perience through the use of interactive 
sound effects overpowers goggles, gloves, 
head-tracking devices, or any of the oili¬ 
er virtual-reality gadgetry out there. Re¬ 
moving the soundtrack plunges die user 
back into the days of silent movies. 

* Music. In film, the musical score un¬ 
folds in a linear fashion. The composer 
knows exactly the amount of time required 
to build up to dial great suspense scene. 
But in interactive games, the suspense 
scene is unknown— it depends on when 
the user opens the dtxjr marked “Pit From 
Hell.” While some games simply score a 
different song for each level, providing al¬ 
most no interactivity, others branch in and 
out of MIDI sequences to create a seam¬ 
less transitions. Some have even attempt¬ 
ed algorithmic music, which is actually 
created in real time by the computer. 

Probably die best middle-ground ap¬ 
proach is to come up with all possible 
variations of emotion you w ish to com¬ 
municate in the product, and then have 
your composer score as if it were for film. 


Your composer should provide branching 
points into and out of these sequences to 
communicate the emotional context in 
pseudo real time. These branches will not 
be instantaneous, but will model the un¬ 
derlying context of the game state very 
closely, such that when you enter a dan¬ 
ger or suspense state, the music will 
branch to reflect that emotion. 

Another approach is to simply use the 
music to communicate the base ambiance 
for the current level, and make heavy use 
of interactive foley, dialogue, and sound 
effects to communicate the action. Obvi¬ 
ously, gunshots, explosions, and screams 
of terror will convey that information to 
the user very well. 

For years, PC developers have had to 
settle for audio devices that could do lit¬ 
tle more then beep, warble, and belch. 
The only emotional reaction we could elic¬ 
it from die user was a deep desire to find 
the “rum music off* button. The First gen¬ 
eration of sound cards wasn't much of an 
improvement. Although newer sound 
cards, such as the Adlib Personal Music 
System, did allow us to add important in¬ 
teractive audio cues to a game, they had 


Digital Sound Engineering for Game Development 


Rob Wallace 

ack in 1990. I decided to expand 
my music services to include sound 
effects and voice tracks tor game de¬ 
velopers and publishers. I was experi¬ 
enced in creating analog foley sound, 
voice tracks, and sound effects for radio, 
TV, and film production, but I discov¬ 
ered that translating analog-audio engi¬ 
neering skills to the digital domain cre¬ 
ated some unexpected challenges. Here, 
TTl present techniques and recommend 
tools which should enable you to make 
your waveforms the best they can be. 

To create and edit professional sounds 
for computer games, you'll first need the 
right equipment for waveform produc¬ 
tion. This equipment includes a sizable 
hard drive (“50 Mbytes, minimum), off¬ 
line storage and shipment devices (QIC 
80 drive, Sy quest 270. or 2/4/8 gigabyte 
DAT drive), and a commercial-quality, 16- 
bit sound card (like tire Turtle Beach Rio). 

For high-resolution applications such 
as Red book Audio, you 11 need a com¬ 
mercial stereo compressor/limiter (I use 
a dbx 166) and a graphic equalizer with 


Rob, who is executive producer of Wal¬ 
lace Music & Sound , can be contacted 
at Wat l MitS'Wix, net com .coni. 


a minimum of 12 dB suppression/ atten¬ 
uation. For low-resolution sound effects 
and voice tracks, 1 suggest the Alesis 
3630 stereo compressor/limiter, Youll 
also want an analog mixer, such as the 
Mackie 1202, along with amps, connec¬ 
tors, and speakers. 

As for software, you 11 need one or 
more sound-effects libraries. I use the 
Sound Ideas Libraries, Hollywood Edge 
Cartoon Trax Library, and my own col¬ 
lection of foley and sound effects ac¬ 
quired over die years. Lastly, youll want 
a waveform creator and editor. After 
working with all of the Macintosh- and 
PC-based toolkits, LVe settled on Sound 
Forge 3.0. from Sonic Foundry, which 
reads/writes standard audio file formats, 
converts one format to another, changes 
sampling rates and bit depths, and syn¬ 
thesizes MIDI files into WAV Files, It also 
lets you capture sounds through sound 
boards or samples from external syn¬ 
thesizers, The program includes all stan¬ 
dard audio-control features, including 
chorus, compress, double, echo, filter, 
limit, and stretch. 

The inherent noise made by aliasing 
and downsampling waveforms demands 
effective algorithms and equalization and 
signal-compression techniques in order 
to achieve acceptable results. Nyquist’s 


Theorem states that the highest fre¬ 
quency you can record is equal to 1/2 
the highest value of the resolution of 
the waveform. At 11.025 kHz, the best 
high-end response you’ll achieve is 
5512.5 Hz. Since the belt cone of the 
audible frequencies of a human voice 
average between 1000 and 3000 Hz, 
you'd think that making waveforms of 
die human voice would be easy. Not 
so, because you first have to filter out 
all frequencies above 5512.5 Hz if you're 
going to make 11.025-kHz resolution 
waveforms. Also, by its nature, aliasing 
introduces undesirable parallel fre¬ 
quencies into the waveform Aliasing is 
analogous to filming a whirling heli¬ 
copter blade at 90 frames per second. 
The visual effect looks like the blade is 
moving in rev erse, or has a "chunky* 
look— quite different than when view¬ 
ing the blade live, 

To prevent aliasing and produce die 
dearest, most-aesthetic low-resolution 
8-bit digital waveform, you severely 
notch out the frequencies above the 
NyquLst- theorem number The depth of 
the notching in dB that you apply de¬ 
pends on the complexity, timbre, and 
harmonics inherent in the original sound. 
This equalization must occur prior to dig¬ 
itizing the sound. 
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limited emotional range. The fundamen¬ 
tal weakness inherent in a cheesy FM syn¬ 
thesis device allowed our orchestrations 
to carry about as much emotional content 
as grade-schooler's FlutoFone, 

With the proliferation of CD-ROM, dig¬ 
ital sound cards, and wave-table synthe¬ 
sis MIDI devices, the situation has im¬ 
proved dramatically. Now we can use 
sound and music in ways that contain 
more emotional content than a Steven 
Spielberg movie which, compelling as it 
is, is a passive experience. We watch the 
dinosaur attack the Land Rover, but we 
have no control over the situation. In an 
interactive game, we are afforded the op¬ 
portunity to try to get away from the di¬ 
nosaur, As we attempt to escape the vi¬ 
cious beast, the music and sound effects 
communicate that emotional distress in di¬ 
rect correlation to our own actions. This 
results in a heightened sense of aware¬ 
ness that only an interactive environment 
can bring. 

One of the best examples of interactive 
digital sound in a gaming environment is 
id Software's DOOM. How many of you 
have jumped back in your chair when you 


heard die eerie “grow ls 1 ' and “snorts’ 1 of a 
monster somewhere around a corner? Al¬ 
though you didn’t see die monster, sim¬ 
ply hearing it precipitated an emotional 
response so strong that when the beast 
lurches out and you cut it down in a hail 
of bullets, you feel a much greater sense 
of accomplishment. These kinds of subde 
audio cues allow r you to orchestrate the 
emotional response in the user. Done 
properly, this effect will bring the game 
player much deeper into the environment 
you are trying to create. 

At this time I should sound a note of 
w r arningj While good use of sound and 
music can gready enhance your software, 
it is easy to do it wrong, Sound and music 
that are of poor quality or that don't sup¬ 
port the emotional direction of your prod¬ 
uct are a waste of time, money, and disk 
space. Bad or unprofessional production 
values, while they may not destroy a prod¬ 
uct, will leave the user with an overall 
poor impression, regardless of how well 
done the rest of elements might be. 

Here are some suggestions of how you 
can make the sound and music in your 
game as effective as possible: 


* Use professional sound effects. Ei¬ 
ther hire a sound-effects specialist or 
be extraordinarily choosy about utilizing 
dip sounds. Do not steal your sound ef¬ 
fects from movies, records, or television; 
this is copyright violation. Your software 
will not be accepted by a publisher, and 
you may even get sued. Just because 
you pull a great Star Trek sound effect 
off of a BBS doesn’t mean you have rights 
to use it. 

* Use professional music. Either hire an 
interactive-media composer or use iiigh- 
quality music clips that fit your project. 
Remember, just as you wouldn't hire a 
bass player to play the saxophone, you 
should be aware that the talent to com¬ 
pose for MIDI and interactive environ¬ 
ments is unique. Being a great musician 
and providing quality MIDI composition 
are not one and the same. Production val¬ 
ues need to be high, and squeezing qual¬ 
ity out of limited music devices is a talent 
your composer will need, 

* Make certain that all of the music sup¬ 
ports the emotional content, theme, and 
direction of the game at any given time. 
Think about the interactive nature of your 


Once the equalization is applied, you 
digitize the sound at the bit depth and 
frequency rate needed. Listen to die play¬ 
back carefully. If the results sound hol¬ 
low' or booming, you have applied too 
many dB of equalization suppression or 
notched too many frequencies above the 
Nyquist frequency. Here you begin to 
learn, in depth, the craft of creating us¬ 
able waveforms. The guiding principle is: 
The lower the bit depth and sampling 
rate, the tougher it is to achieve an ac¬ 
ceptable sound. The timbre, complexity, 
hannomds, original sample quality, and 
dynamic range of the sound you are dig¬ 
itizing will also influence the end result. 

Experimenting with different levels of 
suppression or attenuation of frequen¬ 
cies will give you a sense of the most 
usable sample and w ill help you to make 
educated judgments when making new 
samples. Tire challenge becomes hard¬ 
er depending upon how low r the bit 
depth and sampling frequency plunges, 

A sample wavetbmi can be further ma¬ 
nipulated wadi digital signal processing 
(DSP). You can apply DSP to die sound 
using external hardware (like a Yamaha 
SPX 900) before the signal reaches the 
analog to digital converter (ADC) on your 
sound card, DSP can be algorithmically 
applied directly to the digitized waveform 
after it is created. For game development, 
1 recommend die algorithmic approach. 
Unless you have a high-end profession¬ 
al-audio DSP unit (like the Lexicon), it is 


easy to introduce noise that becomes in¬ 
tolerable when aliased. This is particularly 
noticeable when creating pitch-change 
DSP. Tlie only problem with algorithmic 
DSP is that processing time can become 
lengthy when your samples contain mas¬ 
sive amounts of data (BOOK or greater). 
With the lexicon, the DSP is done in real 
time, so you get to hear and tweak the 
effect prior to digitizing. 

Delay, reverb, chorusing, flanging, 
noise gating, distortion, pitch change, 
and amplitude modulation are common 
DSP effects dial enhance sound, voice, 
and musical waveforms. In game appli¬ 
cations die w aveform must be property 
compressed, I have learned that digital 
samples in games need to be fat and al¬ 
mas! always at maximum amplitude. You 
minimize inherent hiss in low -resolution 
application. Because the sound-wave 
data is as bud as it can be, you are mak¬ 
ing all the possible qualities of die sound 
available to the user by reducing the dy¬ 
namic range of the effect. 

Concession is best applied lief ore dig¬ 
itizing. For game applications, the Alesis 
3630 produces killer waveforms. You sim¬ 
ply set compression to just under the 
liighest ratio it will compress, then en¬ 
sure that die output volume peaks around 
0 dB and that input on the sound card 
matches the 0 dB level of die compres¬ 
sor output. To do tills, get a Shure tone 
generator ( model A1STG), w hich will 
produce a constant tone so you can bal¬ 


ance and create a gain structure. 

Always test your compression by mak¬ 
ing a sample and looking at die wave¬ 
form to see dial it is far and peaks, even 
flattens a bit, at the top. Then listen for 
digital distortion, which appears as a 
crackling pop, or a hard-edged scratch 
resonance. To cure this, lower the out¬ 
put volume of the compressor or in¬ 
crease the compression ratio (or both). 
It is still possible to get some dynamic 
range in low- resolution applications. A 
cricket chirp loop doesn't need to be at 
maximum amplitude or even com¬ 
pressed very much because it is a sub¬ 
tle ambient effect™ but voice tracks 
need to be fat and maximized, 

It is now possible to alter pitch and 
compress or expand the same waveform 
in time, 'Phis means that you can make 
one actor sound like a different person 
by changing his delivery characteristics. 
By applying delay, flange, and chorus¬ 
ing, your own voice can lie used to cre¬ 
ate sounds for horrific space beasts and 
demons of every description. 

Nothing beats the actual experience 
of creating sound effects for a game and 
then heaiing them while you run die ap¬ 
plication. This is die acid test for your 
sound design. You may have to go back 
and change or recreate sounds, but 
when it all comes together and works, 
the effect is dazzling, 
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music and how you want it to shift in con¬ 
text, according to game play. 

* Look at games and movies of a similar 
genre. Every time you watch a movie, try 
to be aware of how your emotions are ma¬ 
nipulated by the music and sound effects. 

* listen to your composer. Look for a 
composer w r ho has an established track 
record composing for the target hardware 
and is familiar with interactive media. 
Communicate very strongly to your com¬ 
poser exactly what you w r ant. Give your 
composer specific music; either from CD 
or film, that matches the emotional con¬ 
tent you want to communicate. 

Effective use of sound and music in in¬ 
teractive games makes the difference be¬ 
tween "experiencing” and merely “play¬ 
ing" them. 

Types of Audio 

The following are several ways to imple¬ 
ment audio on the PC architecture: 

* Digital sound. Ever since the release 
of the Creative Labs' SoundBlaster, the PC 
architecture has had a solid platform for 
implementing digital sound. Other entries, 
including the Co vox Speech Tiling, the 
Walt Disney Sound Source, and Lhe Me¬ 
diaVision ProAudio Spectrum card, all pro¬ 
vide this capability. With digital sound, 
your program can play back anything that 
can be recorded with a microphone— 
digital-sound effects, human speech, mu¬ 
sic, and the tike. Digital sound requires 
enormous amounts of memory and disk 
storage, but it has still been used very ef¬ 
fectively as a method for delivering sound 
effects and voice-recorded responses. 

* FM synthesis. Hie earliest popular PC 
sound card was the Adlib Personal Music 
System, which contained a Yamaha YM- 
3812 COPL2) FM synthesis chip. This de¬ 
vice can create waveforms by using os¬ 
cillators that allow you to apply frequency 
modulation and attack, sustain, decay, and 
release operators to a semiprogra num b I e 
waveform, including a white-noise gen¬ 
erator, If this sounds complicated, it is! 
This device is phenomenally difficult to 
program, and even your best program¬ 
ming efforts sound pretty lame. Fortu¬ 
nately, the importance of FM synthesis is 
declining in the wake of the new gener¬ 
ation of General MIDI wave-table syn¬ 
thesis devices. A number of systems al¬ 
low the YM3812 to emulate a MIDI device, 
thus saving you from having to deal with 
its arcane nature. 

•MIDI. The Musical Instrument Digital 
Interface (MIDI) specification is an inter¬ 
nationally supported, de facto standard 
that defines a serial interface for connec¬ 
tions between music synthesizers, musi¬ 
cal instruments, and computers, MIDI, 
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which is maintained by the MIDI Manu¬ 
facturers Association (Los Angeles, CA), 
is based both on hardware (I/O channels, 
cables, and the Like) and software (en¬ 
coded messages defining device, pitch, 
volume, and so forth). According to the 
specification, the receiving device in a 
MIDI system interprets the musical data 
even though the sending device has no 
way of knowing what the receiver can do. 
But this can be a problem if the receiving 
device doesn't have the capability to in¬ 
terpret the data correctly. General MIDI 
addresses this problem by identifying hard¬ 
ware capabilities in advance. 

All general-MIDI devices have 128 
sound effects as well as musical-instrument 
and percussion sounds. Geneml-MIDl sys¬ 
tems support simultaneous use of 16 MIDI 
channels with a minimum of 24 notes 
each, and they have a specified set of mu¬ 
sic controllers. This means that with gen¬ 
eral MIDI, die sender knows what to ex¬ 
pect of the receiver Consequently, a file 
created with one general-MIDI device is 
recognizable when played on any other— 
without losing notes or changing instru¬ 
mental balance. 

General-MIDI synthesizers available in¬ 
clude the Roland Sound Canvas, the Roland 
RAP-10, the Creative Labs Waveblaster, the 
Logitech Soundwave, the Ensoniq Sound¬ 
Scape, the Gravis Ultrasound, the Turtle 
Beach Multisound, the T urtle Beach Maui 
card, and the Sierra Semiconductor Aria 
card. Additionally, general-MIDI emulation 
Ls available for FM-synthesis devices such 
as the SoundBlaster via third-party devel¬ 
oper toolkits like MIDPAK or the Audio 
Interface Lib ray. 

The future of interactive music appears 
to be the general-MIDI platform, which 
allows you to hire a composer to create 
fully orchestrated scores that will play hack 
at high quality on a large installed base 
of sound cards. MIDI data streams are 
small have a relatively low interrupt rate, 
and require low CPU bandwidth. 

* CD RedBook audio. One benefit of 
CD-ROM drives is that they can play stan¬ 
dard CD audio tracks. However, you can¬ 
not have your software run from the CD 
and play music at the same time. Access 
to the data and audio portions of the CD 
is mutually exclusive, and you cannot 
switch CD audio tracks instantaneously to 
achieve any semblance of interactivity or 
smooth transition. However, many devel¬ 
opers find benefits in placing portions of 
their music score on the CD as an audio 
track, and you may find some uses for it 
in your design. 

• Software digital mixing. With the ex¬ 
ception of die Gravis Ultrasound and the 
Creative Labs AWE32, almost every sound 
card on the market supports only a sin¬ 
gle channel of digital audio. In the con¬ 


text of an interactive environment, you 
want to play many sound effects at once, 
The way to do this is to implement a 
software-based digital mixer. Since sound 
is additive, this is pretty simple: Take all 
the sounds playing at any given time, add 
them together into a buffer, clip for over¬ 
flow, and pass that buffer off to the sound 
card. A number of development packages 
support software-based digital mixing in 
their API specification, 

• Customized, downloadable patches. 
On the Gravis Ultrasound and the Cre¬ 
ative Labs AWE32, an application can 
download musical instalments or digital 
sound effects into memory on the sound 
card itself Once on the card, you can trig¬ 
ger these sounds simply by issuing a MIDI 
event. This Ls a very powerful concept be¬ 
cause not only do you get multichannel 
support, customized instruments, and a 
lower burden on both system RAM and 
CPU, but you can also manipulate those 
sound effects in teal time using pitch shift¬ 
ing, pan-pot controls, and even chorus 
and reverb effects. 

• MOD files. MOD files are a propri¬ 
etary mu sic-file format originally devel¬ 
oped for the Commodore Amiga, MOD 
files effectively create a specification for 
software-based wave-table synthesis. A 
MOD file contains multiple channels of 
music, as well as die actual wave files used 
to perform each instrument. A software 
inteqirerer digitally mixes and frequency 
shifts each sound effect in real time to pro¬ 
duce a .single, digital-audio stream to be 
sent to the sound card. 

MOD files sound great on all sound 
cards. They don’t require MIDI devices— 
any system with a digital channel will get 
the same high-quality music. However, 
MOD files lack adequate audioring tools 
and have huge memory requirements for 
quality files. MOD files used to be a ma¬ 
jor CPU burden due to the overhead of a 
multichannel digital mixer and interpreter, 
but today’s PCs have a great deal more 
processor power, and recent MOD inter¬ 
preters are extremely efficient. 

Conclusion 

Game developers are fortunate to be able 
to draw upon the cumulative experience 
of composers ranging from Mozart, John 
Williams, and Basil Poledouris, to the Bea¬ 
tles. Pink Floyd, and the Benedictine 
Monks of Santo Domingo De Silos, We 
can also leverage the expertise of third- 
party 7 audio vendors who specialize in the 
mechanics of programming sound devices 
at the hardware level. Several systems ex¬ 
ist that relieve you of this burden and al¬ 
low you to focus on the sound and mu¬ 
sic you want to deliver 
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Attached 

Sprites 



as a small ball of fire in the nose of the 
airplane, then grows over the course of 
several frames to a large, smoky fireball 
that eventually covers die entire airplane. 
Finally, the airplane disappears as the 
fireball covers it, and all that is left is the 
fireball, which dissipates and eventually 
disappears as well. 

The motion of the fireball depends on 
the motion of the airplane, which has 
random elements and therefore cannot 
easily be predicted. It is important that 
the fireball sprite knows where the air¬ 
plane sprite is. If two airplanes are ex¬ 
ploding at the same time, it is also nec- 


Diana is senior programmer at Ted 
Gruber Software, publishers of the 
Fastgrapb programmers ’graphics li¬ 
brary ' and author of the book Action 
Arcade Adventure Set (Coriolis Group 
Books, 1994). Diana can be con¬ 
tacted at Fastgrapb@aol.com. 


Figure 1: Sample mid-air battle between airplanes (from the Quickfire demo). 


G ame programmers are always 
looking for efficient ways to ac¬ 
complish sprite animation. As the 
science of game programming 
evolves, certain techniques, such 
as the use of “attached” sprites, have be¬ 
come standard in many games. 

Coasider the case of a dogfight like that 
in the Quickfire demo in Figure 1. A player- 
controlled airplane confronts one or more 
enemy airplanes and shoots bullets at them; 
when an airplane is hit, it explodes and 
dies. To achieve a pleasing visual effect, 
the airplane does not vanish immediately, 
but rather catches fire and gradually be¬ 
comes engulfed in flames before dis¬ 
solving into a puff of smoke. 

Data structures are used to keep 
track of airplanes as they move 
across the scrolling background. 

Each data structure holds an air¬ 
plane’s current x- and y-position, 
its speed, a pointer to the function 
that controls its action (called the 
“action function”), and a pointer to 
a bitmap which describes the cur¬ 
rent image of the airplane. 

An interesting thing happens 
when an airplane explodes. To 


An efficient method 
for sprite 
animation 


Diana Gruber 


achieve the explosion effect, a single 
sprite must become two sprites—one, 
the airplane, which remains unchanged; 
and the other, the explosion, which starts 
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essary to match each explosion with the 
proper airplane. Therefore, you need a 
mechanism to pass information from the 
airplane to the explosion. 


typedef struct OBJstruct 
C 

OBJp next; 

OBJp prev: 
int x: 
int y; 
int xspeed: 
int max.xspeed; 
int yspeed: 
int direction; 
int frame; 
int tile_xmin; 
int tile_xmax; 
int tile.ymin; 
int tile_ymax; 

SPRITE *image; 

ACTIONp action; 

OBJp attached_sprite; 

); 


Example 1: The OBJstruct structure. 


Similarly, the airplane needs to get 
information from the explosion. In 
particular, the airplane needs to know 
how big the fireball is, so it will know 
when it is time to disappear. 

The easiest way to pass information be¬ 
tween the airplane and the explosion is 
to use an attached sprite. The data struc¬ 
tures of both sprites attach themselves to 
each other by simply using a structure 
member to point to each other. The ac¬ 
tion of one sprite is then conveniently in¬ 
fluenced by the status of the other sprite. 

typedef struct .sprite 

C 

char *bitmap; 
int width; 
int height; 
int xoffset; 
int yoffset; 

] SPRITE; 


Example 2: The SPRITE structure. 


All the objects—airplanes, explosions, 
and bullets— are stored in a linked list. 
Because of the nature of the game, nodes 
are constantly being added to and re¬ 
moved from the list. This happens when 
bullets go off the edge of the screen, en¬ 
emies are killed, and so on. An object and 
its attached sprite may exist anywhere in 
the list, as in Figure 2. 

Notice that only the enemy that is cur¬ 
rently exploding has an attached sprite 
and that it is possible for the player to 
have an attached sprite. When the player 
is hit, a small fireball appears, even though 
the player does not die from the strike. 
When there is no explosion, the attached 
sprite is set to NULL 

The OBJstruct structure holds the in¬ 
formation about each sprite object, in¬ 
cluding airplanes, bullets, and explosions. 
In this structure (see Example 1), the first 
two memlx^rs are the pointers to adjacent 
nodes in the linked list. The next two 
members, jcand y, specify the current po¬ 
sition of the sprite. These values change 
in each frame according to the speed and 
direction of the sprite, which are described 
in the next five members. The frame mem¬ 
ber describes something about the ani¬ 
mation: whether the plane is upright or 
turning, for example. The next four ele¬ 
ments specify the tile extents and are used 


player-bullet-enemy-bullet-bullet-explosion-bullet-enemy-explosion 

A J ; j ; A 

A A 

T T T T 

T j 

I NULL NULL NULL NULL j 

NULL ; 

attached sprite pointer 



Figure 2: Objects in the list may point to each other or to nothing 
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to determine when an object has moved 
off the edge of the screen. 

The image member is a pointer to die 
object’s bitmap data, which is the actual 
physical representation of the sprite. This 
Is stored in the SPRITE structure, as in Ex¬ 
ample 2. This structure holds all the in¬ 
formation necessary to display the sprite, 
including its width and height, and the 
offset values. The offsets are used to ad¬ 
just die position of the sprite and are es¬ 
pecially useful with explosions, which 
need to be centered around their midpoint 
rather than displayed from a comer. 

The action member of the object struc¬ 
ture is a pointer to a function, such as the 
do_exphsion() function in Listing One 
(page 34). This function is an action func¬ 
tion and is executed once each frame. It 
determines the current state of the object, 
such as going, falling, or dying. 

The final member of the object struc¬ 
ture, OBjp aUached_sprite, is a pointer to 
another object structure; in other words, 
the pointer to the attached sprite. The 
pointer is always bidirectional, meaning 
the object points back to whichever ob¬ 
ject points to it. 

Tiie code that controls the creation of 
the explosion is shown in the function 
start^expfasicmf); see Listing One, As you 
can see, this function spawns an object 
and adds it to the linked list in the tradi¬ 
tional way. It also forms the attachment 
between the airplane sprite (obp) and the 


objp 

*-] r > 

node 

attached 

L-f-~ 

attached 

sprite 


sprite 


airplane explosion 


Figure 3: The airplane and the 
explosion point to each other. 


explosion sprite (node)] see Example 3 
and Figure 3- 

The motion of the explosion is con¬ 
trolled by the function do_explosion(X 
This function firsL examines the current 
state of the explosion. If the state of the 
animation has reached the third frame, die 
explosion is big enough to cover the air¬ 
plane. At that point, it Ls time to kill the 
airplane by setting its action function to 
killjenemyCX as m Example 4. 

After the enemy airplane has been 
killed, the attached sprite is set to NULL, 
indicating there is no longer an airplane 
attached to die explosion. The explosion 
may now move independently for the next 
few frames, until it also Ls killed. 

During those three frames when both 
the airplane and die explosion are visible, 
the x- and y-coordinates of the explosion 
are determined by the x- and y-coordinates 
of the airplane, as in Example 5- These 
coordinates include a 16-pixel horizontal 
adjustment and a four-pixel vertical ad¬ 
justment to center the explosion over the 
nose of the airplane. 

Attached sprites have many applica¬ 
tions. When a character needs to hold an 
object, such as a gun, attached sprites can 
greatly simplify the code. This also saves 
room, which is always at a premium when 
designing games. If you have a sprite with 
30 positions (running, jumping, falling, 
standing, and so forth) and you add a gun 
to each of those positions, you will need 
to generate 30 more sprites, if the sprites 
have an average width of 30 pixels and 
height of 40 pixels, this will use 36 Kbytes 
of sprite space. If you can reuse the non- 
shooting sprites by simply adding an at¬ 
tached gun arm to each one, the savings 
in RAM and disk space will be significant. 
(For more information about sprite ani¬ 
mation, see Chapters 12 and 13 in my 
book, Action Arcade Adventure Set.) 


ATLANTA/DALLAS 


Maximize Your 
Client/Server 
Experience. 

Whether you're seeking a contract or 
permanent placement, MATRIX can max¬ 
imize your potential in the Atlanta or Dallas 
marketplace. Our Staffing Specialists have 
the proven methods, marketplace knowl¬ 
edge and industry expertise to efficiently 
match you with your greatest opportunity. 
Currently, we have Client/Server positions 
featuring the following skills: 

• Visual BASIC • Windows NT 

• Visual C++ • PeopleSoft 

• OS/2 • ORACLE 

• Sybase • PowerBuilder 

• Borland C++ • Clipper 

• MS Windows * Access 2.0 

• UNIX/C • Lotus Notes 

Contact our Staffing Specialists: 

ATLANTA 

Lambert Chandler 

Ph: 404-393-9933 Fax: 404-668-0384 

DALLAS 

Paul Hand 

Ph: 214-386-9732 Fax: 214-980-4128 

MATRIX, 

I n te met: 74740.2045@ compu serve .com 

Never a tee to candidates. 


DICE IS LOOKING FOR... 


...data processing, engineering and technical 
writing professionals to fill open positions 
nationwide. DICE is a FREE online job search 
service providing detailed information about 
current contract and full-time positions across 
the USA, It's a confidential, easy to use, no 
cost way to search for □ new job 


A D ATA PROCESSING 
I NDEPENDENT 
C ONSULTANTS 
E XCHANGE 

ONLINE NUMBER 
515 - 280-3423 


Contact DICE via 1200/14400 baud 
Modem, 8-N-l or Internet: telnet dice.com 
A service of D&L Online, inc 
(515) 280-1144 


DDJ 

(listing begins an page 34,) 

/* set up the links between the explosion and the enemy plane */ 
node->attachad_sprita = objp: 
objp“>attached_sprite ~ node: 

Example 3t The portion of the start_explosion() function that attaches two 
sprites to each other. 


if (objp->attached_sprite != (QBJp)NULL) 

objp->attaehecLsprite->action = &kill_enemy: 


Example 4: Setting a sprites action function. 


/* The position of the explosion depends on the position of the airplane */ 
if (abjp->attached_sprite != (QBJp)NULL) 

t 

objp->x = objp->attached„sprite^>x+16: 
objp->y - objp->attached_sprite->y“4: 

J 


Example St Determining x a n d y- coordinates. 
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Programming Expertise 


The new and improved Dr. Dobb’s/CD 
puls in your hands all the articles and source 
code from January 1988 through June 1994, 
plus all the special issues and previously 
unpublished source code. Only Dr. 
Dobb’s/CD puls the programming perspec¬ 
tives and innovations of the best program¬ 
mers in the industry at your fingertips. It’s 
the ultimate programming resource. 

Dr. Dobb's/CD 
does the groundwork 
lor you 

Why reinvent the wheel? Dr. Dobb’s/CD lets 
you copy code directly into your projects. It’s 
great to have whether you’re trying to solve a 
specific problem, or just exploring a new tech¬ 
nique. See how other programmers overcame 
challenges similar to yours. Incorporate bril¬ 


liant, lasting programming gems into your 
own approach and take them to the next level. 

Get valuable 
information fast 

Dr. Dobb's/CD puts valuable time on your 
side. Powerful and intuitive search capabilities 
make locating the information you need easy 
and fast. Access information using the title, 
author and listing indexes. Or use the CD-ROM’s 
search capability to get to key words across the 
full-text, issue, title, author, year, or listing. 
Boolean and wildcard functions are included to 
make searching even more flexible. Uncover 
new ideas as you search. Document your 
paths. Annotate key material with electronic 
notes and save them to your hard drive. You 
can even use handy bookmarks to save your 
place anywhere on the CD-ROM. 


on Demand 

Your personal 
electronic archive 
at a price you can't 
afford to pass up 

Dr. Dobb’s/CD could be the most sophisti¬ 
cated, comprehensive archive of programming 
tools you’ll ever find. Run your Dr. 
Dobb’s/CD on DOS or Windows and put the 
expertise of Dr. Dabb's Journal to work for 
you. Order your CD-ROM today! 

Dr. Dobb's/CD is available for $79 95, plus 
shipping ($2.00 US/Canada, if 12.50 all other), 
We accept Visit, MasterCard, American Express, 
checks or money orders. See the attached 
order form. 















Alternative Programming Languages CD-ROM 


The Alternative 
Programming 
Languages CD-ROM 
is your resource for the 
latest in cutting-edge 
programming 
environments. Get up 
to speed on distributed 
computing, embeddable 
languages, increased 
productivity, and 
languages of the future. 


You get all these languages, compilers, interpreters: 

Perk Glish, Smalltalk, Sather, Tel, MO, 
Modula-5, ReXX, Loot, Gliostecript Dylan, 
Duel, Bob, Neudl, Python, Oberon, Parasol, 
S-iiuig, Quincy, uSystems, Distributed C, 
the GNU compiler suite— and more! 


m Text processing and 
document formatting: 

Lout and Ghostscript let 
you edit and produce com¬ 
plex documents with ease. 



Put this CD-ROM to work immediately on your devel- 
opment projects: 


• Prototyping; When pro¬ 
totyping connected distributed systems, Clish makes it 
ail happen for you. 


• Object-oncnted development: Tired of C++? 

Look no further than Sather, Dylan or Bob and get re¬ 
energized. 


• Neural networks: Neudl takes the pain out of 
building complex neural networks. 


• Distributed computing: When bn tiding distrib¬ 
uted systems, languages like Parasol and MO make 
your life easier. 


i And much more! 


• Multiple platfonns: Check out Perl and Python, 
plus a wide range of compilers, including the GNU 
compiler suite. 


All these languages are robust, imaginatively 
designed, break new technical ground, and come 
with source code for compilers or interpreters. 
What’s more, full descriptions and specifications are 
provided 


PSt 


With your purchase of this CD-ROM, you'll also receive a copy of the Dr. Dobb’s 
Sourcebook of Alternative Programming Languages A $4.95 value—ABSOLUTELY FREE! 
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high-performance UNIX 
operating system for the 

with the developers by 


• ANNOTATIONS by the developers highlight 
key kernel source files. You’ll see how each module 
works and why, what the tradeoffs and alternative 
approaches are—and where 386BSD might be 
heading next Many of these annotations have never 
been published and are available only on tins CD. 


tion provide an exciting 
environment to explore 
this high-performance 
system. 



your 

Th^3S6BSD Rejermie CD-ROM official release 1.0 
includes the source axle of a complete operating sys¬ 
tem based on Berkeley UNIX for the PC Plus, a 
weald of resources, articles and reference materi¬ 
als—written by William and Lynne Jolite, the sys¬ 
tem’s designers. Major features include: 


• ARTICLES that appeared in Dr : Dobb ’s 
Journal, the complete “Porting UNIX to the 386” 
series, explain the genesis and evolution of die oper¬ 
ating system’s design. From specification to execu¬ 
tion, the development methodology is laid out 


Your 386B5D is powered by a fully multitasking 
kernel containing full interprocess communications 
and networking protocols (TCP/IP), and advanced 
virtual memory subsystem, fast filesystems and 
drivers—representing 20 yearc worth of research by 
world-class programmers! 


• INDEX® throughout This CD-ROM comes 
with a hypertext indexed database dial makes infor¬ 
mation instantly accessible. 


• SOURCE CODE for the entire system, including 
the kernel and utilities, are instantly accessible so 
you can see how a complete operating system is put 
togedier. Also included are binaries for supported 
PC configurations. 


Explore, analyze, even recompile the system itself. 

Do development work on the 3S6BSD while running 
the system—whether for serious software research 
or just hacking the kernel, C and C++ libraries. 

XI1R5, tools and utilities, and on-line documenta¬ 


YOUR CD-ROM INCLUDES: 

• Bootable CD 

• Viewable in DOOTindows 

• Mountable as a UNIX file system 

• X-Windows 
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SPRITES 


Listing One * Text begins on page 29.) 

/***«*************■** sprite declarations iMutititituuUtitMit/ 
int nspritea; 
typedef struct .sprite 
t 

Char ‘bitmap; 
int width: 
int height 3 
int xoffset; 
int yoffeett 

} SPRITE; 

SPRITE *fcprite[4a]t 

h forward declarations */ 
struct DBJstruct: 

typedef struct OBJstrtict DBJ, near *0BJp: 

/* pointer to object action function */ 
typedtf void near ACTION (QBJp objp)j 
typedef ACTION *ACTIOWpr 

/* data structure. for objects */ 
typedef struct QBJetnict 

l 

OEJp next: 

OBJp prev: 
in t x; 
int y; 
int xspeed; 
int max.xspeeth 
int yspeed; 
int direction; 
int frame; 
int tile^mdn; 
int tila.Kimax; 
int tilo-ymin: 
int tile.yfcex; 

SPRITE ‘image; 

AClTQNp action; 

OBJp attached-Bprite: 

1 : 

SPRITE *eapIoEion[ilj; 


void near start.explosion(OBJp objpj 

t 

OBJp node; 

/* allocate apace for the object */ 
rode - (QBJp)nLiIloctsiaso.f (DBJ}J; 
if (node == (OBJp)NULL) return; 

/* assign values to the Structure members */ 

/* after the plane has been killed, the explosion moves at a slower 
speed because smoke drifts slower than Metal */ 
node->xspeed = objp->xspead/2; 
node-S-yspeed = objp->yspeedl/Jl; 

/* tile extents ♦/ 
node->tile_xmin = 2; 
node-*tile_HMi - 21; 
node-> tile, ymin * 0; 
node->tile.yrnax » 14; 

/* the sprite win be the first frame explosion bitmap */ 

node->image = explosion [0]; 

node->x = objp->x+l6; 

node->y = Dbjp->y-4; 

node->freme = -J; 

/* insert at the top of the linked list */ 

ncde->ptev = top_node: 

node->prev->next - node; 

top,node ■ node; 

node->next * (OBJp)HCLL; 

h set up the links between the explosion and the enemy plane *J 
node->attached_sprite - objp; 

Dbjp->attached_sprite - node; 

t* assign the action function */ 
node->action = do.explosion; 

} 

/****************************************** . ******************* 

void near do_explofiion(OBJp objp) 

( 

/* If the explosion has reached the frame l state r at which point 
the bitmap is bigger than the airplane. it is time to kill the 
airplane. */ 


You Can afford a 
Sound Designer! 

so can you really 
afford not to have one? 

To take your project to the highest level 
of sound expression; the music, sound 
effects, ambient DSP, foley, stereo, 3D 
imaging, equalization, and your vision all 
have to work together. Wallace Music & 
Sound can make these elements come 
together for your project 

here '$ why you can afford the best: 

Generous points, subcontract or buy-out 
terms are available for qualified developers, 
CGDA members and all CGDC 95 attendees. 

. Call Rob Wallace for a quote and let's talk 
about your project. Let the Sound Designers 
chosen by so many top developers & 
publishers work for you! 

Wallace Music & Sound, Inc. Rob Wallace, Executive Producer 

Member: CGDA, ASCAP, & tASIG of the MMA 
6210 West Pershing Avenue - Glendale, AZ.. 85304 - Voice: 602.979.6201 
WaJIM^Lxnetconi earn ^24Hr BBS & FAX 60C.4118555 


if (objp->frame > 


/* if the attached sprite is NULL thst means the airplane wag 
already killed */ 

if (oh jp->attachfrd__Jiprite !■ (OBJp)NULL) 

objp-JatTaehed^spcite-Jaction * tkill.enemy; 

pbjp->X *= ubjp-^ispeed; 
qbjp->y += objp->yspeed; 

3 

else 

{ 

/* The position of the explosion depends on the position of 
the airplane */ 

if (objp->attached_sprite 1= (QBJp)NULL) 

( 

objp->x m □bjp->flttaehad i .fiprite->x+lh; 
objp->y ■ objp->attached.aprite->y-4: 

I 

/* it is possible for the explosion to he at 1#S6 than frame 3 
but there is no attached sprite. That happens when the enemy 
plane has drifted off the edge of the screen. */ 
else 
( 

cijp-lx objp->xspeed; 
objp->y +■ abjp->yspeed: 

3 

) 

/* Increment the explosion frame •/ 
ob]p->frajae++; 

/* define which sprite will be displayed this frame */ 
objp-Jimage * explosion[objp->frame]: 

/* Ve have 10 itmaes for the explosion */ 
if (objp-Jftame > 10) 

I 

abjp-iimage = explosion f10j; 
objp->ection - kill.explosion; 

} 

End Listing 
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VESA 2.0 


Using the VESA BIOS 2.0 

Linear Frame Buffer 



Performance 
enhancement 
with and 
without bank 
switching 


Brian is a graphics researcher spe¬ 
cializing in the field of real-time 3-D 
computer graphics. He currently 
works for a 3-D graphics hardware 
firm and is the author of Building a 
3D Games Engine in C++ (John Wi¬ 
ley & Sons, 1995), He can he con¬ 
tacted at hwh@netcomxom, Kendall 
is the lead developer at SciTech Soft¬ 
ware, which has developed the Uni¬ 
versal VESA VBE r MCI graphics li¬ 
brary, and recently, WinDirea, He 
can be reached at KendallBWScitech- 
Soft.com * 


Compatibility and the VESA BIOS 

Manipulating a video card’s banks requires 
in-depth programming knowledge of its 
video chipset. Supporting a multitude of 
video cards, however, can be arduous. To 
circumvent this, VESA designed and im¬ 
plemented a standard BIOS interface that 
supports bank switching and other func¬ 
tions for a wide range of video cards. This 
allows you to program for the VESA BIOS 
without supporting a specific video card’s 
idiosyncratic bank-switching mechanisms. 
If a video card is VESA compatible, you can 
be reasonably sure that your code will run. 


The Banking Performance Penalty 

While the original VESA BIOS specifica¬ 
tion provided a hardware-independent 
method to access all of a video card’s dis¬ 
play RAM, there was a significant 
performance penalty because bank¬ 
ing is inherently slow. For starters, 
bank switching is expensive, since 
the VESA BIOS interface is accessed 
via software interrupt 0x1(1 Not only 
is the interrupt slow, but there is a 
potential context switch from pro¬ 
tected mode to real mode and back, 
compounding the expense. This, 
coupled with the significant book¬ 
keeping overhead dial bank switch¬ 
ing imposes (bank boundaries must 
be watched for at all times during 
operations such as line drawing rect¬ 
angle clears, and so on), makes 
banked frame buffers inefficient for 
getting to a video card’s RAM, 


Linear Frame Buffer 
versus Banking 

To address die problems of banked 
fra me-buffer access, the VESA com¬ 
mittee has designed and ratified the 


Brian Hook and 
Kendall Bennett 


H igh-performance graphics ap¬ 
plications under DOS typically 
require direct access to the 
graphics card's frame buffer. On 
the VGA, this memory is ac¬ 
cessed in the memory region from 
A000:0000 to A000:FFFE Since this allow s 
only 64 Kbytes to be accessed at a time 
on a VGA, accessing all of the memory 
on the VGA card requires a banking 
scheme. With a banking scheme, a win¬ 
dow into a part of the frame buffer is ad¬ 
dressed at AOOthOOQQ, but the piece of 
frame buffer this window' points to can 
slide around, While this allows all of the 
memory on the video card to be ac¬ 
cessed, it requires that the frame buffer 
be dealt with in 64-Kbyte chunks—a 
programming hassle at best, a serious 
performance degradation at worst. 

To combat this problem, the Video 
Electronics Standards Association 
(VESA) has implemented, as part of 
its VESA BIOS Extension (VBE) 2.0, 
a method by which a pointer to a 
linear frame buffer can lie obtained 
by an application running on a VBE 
2.0-compliant graphics system. 


Dr. Dobh’s Sourcebook , May /June 1995 


35 








VBE 2.0 specification. This major overhaul 
of the VBE interface introduces two 
performance-enhancing capabilities. The 
first is protected-mode bank switching, 
which removes the need for expensive 
context switching when banking. Tile sec¬ 
ond capability removes the need for bank¬ 
ing altogether by handling the frame buffer 
as a single chunk of contiguous memory, 
assuming that the underlying hardware is 
capable of supporting such access. This 
is important, since VBE 2.0 doesn’t guar¬ 
antee the existence of linear frame-buffer 
access—it only provides an interface to 
die linear frame buffer if it exists. Linear 
frame-buffer support possesses many of 
the same advantages the 32-bit flat mod¬ 
el has over the 16- bit segmented memo¬ 
ry model of the Intel processor—simpler 
addressing, no segment/bank swapping, 
and access to a larger address space. 

As a fortunate side effect, VBE 2.0's lin¬ 
ear frame-buffer access usually provides 
significantly improved performance on 
PCI-bus-based video systems. Specifical¬ 


ly, when dealing with the VGA frame 
buffer at AQOO:OOOQ on PCI systems, PCI 
burst mode is usually not available. How¬ 
ever, when working with a video card's 
frame buffer, linear burst mode is avail¬ 
able, and performance can double Cor 
more) during mass-data transfers. 

Accessing the Linear Frame Buffer 

Acquiring a pointer to a graphics system’s 
linear frame buffer is a simple but lengthy 
process, requiring care since a misstep at 
any point renders the frame buffer invalid 
The steps involved are: 

• Getting VESA Super-VGA information, 
such as VBE revision number. 

• Determining if the desired linear video 
mode is available. 

• Creating a 48-bit far pointer to access 
the linear trance buffer. 

Getting VBE Super-VGA Information 

The function VBE_detect() first executes 
VESA function 0 (Get SuperVGA Infor¬ 


mation), which fills in a VGA info block. 
The VBE is accessed via the standard 
video interrupt lGh; however, AH is set 
to 4Fh so that the VBE knows to inter¬ 
cept the call, and AL is set to the VBE 
function number, After the call has been 
performed, the routine returns die VESA 
version as a BCD value. The video¬ 
mode list returned in the VGA info 
block must be copied into another 
buffer, because the VGA info table will 
be clobbered by any calls that use this 
area of memory (for example, a call to 
get information on a specific video 
mode). 

Finding a Video Mode 

In VBE 2.0, VESA lias dropped the poli¬ 
cy of introducing hardcoded video modes. 
Instead, you can query die hardware di¬ 
rectly tor a video mode with a certain set 
of attributes. The AvailahleModes( ) func¬ 
tion searches the video-mode list for those 
video modes that fit a specific applica¬ 
tion’s criteria. 


Frame-Buffer Performance Metrics 


T he ability to quantify fra me-buffer 
performance is important because 
such performance is often directly 
proportional to the performance of a 
game or other type of graphics applica¬ 
tion. However, measuring frame-buffer 
performance accurately (and in a form 
where the results can he interpreted 
meaningfully) is tricky and often con¬ 
troversial. 

Let’s take as an example a very naive 
VGA frame-buffer performance test. Such 
a test would consist of repeatedly blit¬ 
ting out a 320x200, 8-bit, off-screen 
buffer to die VGA mode 0x13 real-mode 
address space from AQQG:0G0Q to A000: 
FFIT. Time would be measured using the 
clockf) standard-library function, with 
enough test-loop iterations to factor out 
the fairly coarse granularity typical of PC 
system timers (18,2 ricks/sec), The inner 
loop of such a test would be straight¬ 
forward, as Example 1(a) shows. This 
would seem to give a very good indica¬ 
tion of a system's capability to update 
VRAM, but this isn’t necessarily true. A 
benchmark attempts to determine not 
only the video card’s peak speed, but 
also its likely real-world performance. 
Often, the two are not even dose. 

Sequential Transfer versus 
Random Access 

Our sample test has several significant 
flaws when it comes id real-world perfor¬ 


mance measurement. The first, and most 
obvious, is that it only tests tile speed of 
sequential writes to the video card from 
system RAM This is fine for many appli¬ 
cations, but for programs that do random 
writes to video, this type of measurement 
can lie misleading. For example, video 
chips widi interleaved memory access (S3 
805i, Tseng Libs ET4000/w32i) typically 
have extremely fast sequential transfer 
rates because the interleaved RAM is op¬ 
timized for just this type of action. Ran¬ 
dom writes on these boards, however, 
are not nearly as fast as their sequential 
write times might imply. 

Additionally, sequential transfers usu¬ 
ally trigger PCI burst-mode operation on 
PCI bus systems, which significantly in¬ 
creases transfer speed, but only during 
blits. This can easily lead to misinter¬ 
pretation of transfer rates as measured 
by a naive benchmarking program, since 
burst transfer rates are significantly liigh- 
er than random-access rates. 

Also, the standard-library memcpyO 
function used in our naive benchmark 
isn’t guaranteed to decompose the 
system-to-video copy into 32-bit read' 
writes. If memcpyO were implemented 
using MOVSR, for example, an 8-bit 
video card w r ould likely have the same 
performance as a 32-bit video card (as¬ 
suming techniques such as byte-merging 
w ere disabled in system-chipset setup). 

Another deficiency is that this bench¬ 


mark only tests VGA mode 0x13 per¬ 
formance. This does not necessarily 
scale accurately to other video modes, 
such as tweaked, planar, VGA 8-bit 
modes (“ModeX") or high-resolution 
VESA modes. There are many reasons 
for this. For starters, different chipsets 
behave differently depending on the 
video mode; some chipsets have poor 
planar performance but reasonable 
packed-mode performance. Another 
reason is that some video cards handle 
different video modes with different 
video chips; the Diamond Viper, for ex¬ 
ample. Video mode 0x13 is handled by 
a secondary VGA processor, such as an 
OAK or Weitek 5x86 standard VGA chip, 
whereas VESA m<xle 640x400x8 (used 
by Microsoft Flight Simulator 5) uses 
the Weitek P9000 accelerator natively. 
As a result, mode 0x13 on the Viper is 
extremely lackluster, yet the high- 
resolution VESA mode is almost breath- 
Lakingly fast. Also, the sheer size dif¬ 
ference of the different video modes 
(mode Oxl 3 requires only 64,000 bytes, 
whereas a mode such as 1024x768x32- 
bit can consume over three million bytes) 
can greatly affect cache coherency. 

Note that DRAM and VRAM boards 
do not perform the same in all video 
modes. In very-low-resolution modes 
like VGA mode 0x13, little time is re¬ 
quired by the CRTC controller to refresh 
die display, leaving nearly all the DRAM 
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Get a Painter to the Frame Buffer 

The GetPtrToLFBf) function is responsi¬ 
ble for returning a 48-bit far pointer to the 
linear frame buffer The process is some¬ 
what lengthy but easy to understand. 
DPiVH service 0 is first used to allocate a 
selector, as implemented by DPMI_alloc- 
SelectotfX Note that this function imme¬ 
diately sets the selector's access rights to 
32-bit page granular Next, the newly al¬ 
located selector must have its base address 
set to the address of the frame buffer. 

This gets a little sticky, because the 
physical address of die frame buffer (as 
given in the VBE_modeInfo structure) is 
not the same as the linear address the se¬ 
lector expects as a base address. IPs there¬ 
fore necessary to use DPMI service 0x800 
to map the frame buffer's physical address 
into the processor's currently running lin¬ 
ear address space. The function DPM1_ 
mapPhysicalToLinearf) performs this 
chore. 

With linear address in hand, the selec¬ 
tor's base address is set using DPMI service 


bandwidth available for CPU access. 
However, in the very-high- resolution 
modes like 1280x1024x256, much more 
t of the DRAM bandwidth is required by 

the CRTC controller; hence, frame-buffer 
performance will drop significantly, With 
boards based on dual-ported VRAM, the 
CPU and CRTC controller can bodi gain 
access to the memory at die same time; 
therefore, the performance generally 
does not degrade as die resolution in¬ 
creases (making VRAM boards popular 
for high-end CAD applications that need 
high-resolution video modes). 

Cache Coherency 

External (L2) cache coherency is ex¬ 
tremely important in characterizing 
frame-buffer performance. Modem com¬ 
puter systems can have caches anywhere 
from nonexistent to 512K in size. This 
cache proves very important in real- 
world tests, but in an application-specific 
(and thus unpredictable) manner. In 
general, if the effect of a factor on an 
application's performance is unpre¬ 
dictable, then an attempt should be 
made to remove it from the benchmark. 
A good benchmarking program should 
try and minimize the effects of the L2 
cache as much as possible. The naive 
benchmark presented earlier does not 
* do this, and as a result will find signif¬ 

icantly better performance on a system 
with a 256 k cache than on one without 
any cache, solely because the source 
buffer will reside in the L2 cache for the 
duration of the program. To defeat 
cache coherency, two techniques can 


7, as DPM_setSelectorBase() demonstrates. 
The only thing left now is setting die se¬ 
lector's limit, which is done using DPMI 
function 8 (DPMljsetSelectorLimit ()). 
LFBPROF sets the limit to 4 Mbytes, since 
this is the most memory any modern VESA- 
compatible video card will likely have. (Be¬ 
cause we made the selector 32-bit page 
granular, the limit passed must be in 4K 
increments and set to the value of limit-1.) 

At this point, a selector has been se¬ 
cured that maps direcdy into the video 
card's frame buffer. This selector forms the 
basis of a far pointer. The macro MK_FP() 
in dos.h (which is Watcom C++ specific) 
creates a 48-bit far pointer out of the se¬ 
lector This pointer allows linear access to 
the frame buffer. 

Accessing the Frame Buffer 

The linear frame buffer can no%v be ac¬ 
cessed either direcdy in assembly or us¬ 
ing Watcom's far-memory routines (for ex¬ 
ample, _fmemcpy() and _fmemset()). 
The sample program, LFBPROF ("Line 


Frame Buffer Profiler"), uses Watcom in¬ 
line assembly to gain access to the frame 
buffer, since we must guarantee that data 
is packed in 32-bit dwords as it goes 
across the bus. The functions LfbMem- 
cpyf ) and LfbMemsetO in LFBPROF. 11 are 
implemented as Watcom inline assembly 
and are guaranteed 32-bit memory' copy¬ 
ing and setting routines, 

LFBPROF 

LFBPROF implements everything weve 
discussed to this point, including banked 
fra me-buffer access. LFBPROF is a video- 
card benchmarking program that tests the 
ability of the underlying hardware to han¬ 
dle system-to-video copies and frame- 
buffer clears in both banked and linear 
frame-buffer modes. (For more informa¬ 
tion on benchmarking frame buffers, see 
the accompanying text box entitled, 
“Frame Buffer Performance Metrics.”) 
Listings One (page 39) and Two (page 41} 
contain the complete source to LFBPROF. C 
and LFBPROF.H, respectively. The com- 


(a) for (1 = 0: i < NUfL ITERATIONS; i++ ) 

[ 

tceiEcpyC video, fiovrce.baffer, SRC_EUF^SIZE ); 

} 

(b) for ( i = 0; i < NUM_ ITERATIONS ; i++ ) 

[ 

mentcpyC video, source.btiffer[i^NUN_SRC_BUES] . SRC_BUF_SIZE ) ; 

} 


Example 1: (a) Inner loop of test / (b) cycling through multiple buffers. 

Conclusion 


be used. T he first is to simply step 
through multiple buffers. In Example 
Kb), cycling through multiple buffers 
instead of using a single 64K buffer pret¬ 
ty well destroys cache coherency. Tills 
makes for lower benchmark figures, but 
they reflect real-world performance 
more accurately. 

The second method of defeating cache 
coherency Is to simply use a video mode 
larger than the system's external cache. 
A video mode such as 640x480xl6bpp 
consumes 600K, well beyond die size of 
a typical L2 cache. 

When measuring frame-buffer perfor¬ 
mance, most focal buses will operate at 
a different speed, depending on the pro 
cessor installed. For example, a PCI-bus 
Pentium/66 will generally blit faster than 
a PCI-bus Pentium/90 because the for¬ 
mer clocks die PCI bus at 33 MHz (clock 
halved) and the latter, at 30 MHz (clock 
thirdedX This can't be accounted for by 
the benchmark, but it should be noted 
when analyzing performance character¬ 
istics of different video cards measured 
in different systems. 


With so many factors, it would seem 
nearly impossible to devise a single, 
ideal benchmark, However, a compre¬ 
hensive benchmark isn't necessarily 
better than an accurate, informative 
one. The most important criterion for 
any measurement tool is that it speci¬ 
fy clearly what is being measured, how 
it is being measured, and what appli¬ 
cations will find the benchmark's data 
relevant. Accurate, comprehensive data 
is useless unless it is easy to under¬ 
stand and translates into relevant, 
meaningful results. LFBPROF does not 
claim to provide comprehensive data 
on a video card’s performance, instead, 
it simply states the performance of a 
video card when using VBE 2,0 ? s lin¬ 
ear frame-buffer feature for clearing 
and system-to-video copying opera¬ 
tions, Such performance is very im¬ 
portant for games, but often absolute¬ 
ly irrelevant for other applications such 
as CAD or GUIs. 

— B H. and K.B, 
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The Greatest 
Thing Since 
Sliced Bread 


No matter how you slice it, our free Consumer 
Information Catalog is great food for thought. 

The Catalog dishes up more than 200 free and low-cost 
government booklets on subjects you can really sink your 
teeth into — such as staying healthy, eating right, finding 
a job, getting federal benefits, using credit, buying a 
home, helping your kids, taking care of your car, and 
much, much more. 

To get your free copy, send your name and address to: 

Consumer Information Center 

Department GT 

Pueblo, Colorado 81009 

A public service of this publication and the Consumer 

Information Center of the U S. General Services Administration 



Plant Trees for America 





GtntiemixkfOfatsf 

jf&t pa* f*ti am 


10 Free Trees 

T en Colorado blue spruces, 
or other conifers selected 
to grow in your area, will be 
given to each person who 
joins The National Arbor Day 
Foundation, 

Your trees will be shipped 
postpaid at the right time for 
planting in your area. February 
through May in the spring or 
October through mid Decem¬ 
ber in the fail. The six to 
twelve inch trees are guaran¬ 
teed to grow, or they will be 
replaced free. 

To become a member 
and to receive your free 
trees, send a $10 member¬ 
ship contribution to Ten 
Blue Spruces, National 
Arbor Day Foundation, 100 
Arbor Avenue, Nebraska 
City, NE 68410. 

Join today, and plant 
your Trees for America! 


The National 
f Arbor Day Fomidation 


piler used was Watcom C/C++ 10.0a us¬ 
ing the 32-bit flat model, with DOS- 
4GW.EXE as the DOS extender. Because 
the VBE 2,0 is so new, few hardware man¬ 
ufacturers have implemented the spec in 
their ROMs, so SciTech Software’s Uni¬ 
versal VESA BIOS Extensions TSR (Uni- 
VBE) must be used as die VESA BIOS 


The VBE 2.0 spec 
allows for handling 
the frame buffer as a 
single chunk of 
contiguous memory 


interface provider. This package is share¬ 
ware and available at most DOS ftp sites, 
including ftp.scitechsoft.com, and on 
CompuServe GO IBMPRQ, 

LFBPROF takes two arguments on the 
command line, which are the resolution 
of the desired video mode; for example, 
to test 640x480, the command line is 
LFBPROF 640 480. 

If no arguments are given, a list of avail¬ 
able video modes is printed. Note that 
only 8-bit linear fra me-buffer modes are 
tested, although it would be relatively 
straightforw ard to add support for 15- bit 
and higher modes to LFBPROF. Listing 
Tfiree (page 41) is a sample makefile that 
can be used to compile LFBPROF, 

LFBPROF’s mainO is subdivided into 
three basic parts; initialization, bench¬ 
marking, and shutdown. Initialization is 
responsible for determining VBE 2.0 com¬ 
pliance, checking on the availability of the 
desired video mode, and initializing the 
graphics mode (which includes securing 
a selector to die linear frame buffer). 

The benchmark tests a video card's 
frame-buffer clearing and setting speed 
using LFBPROFs LfhMemcpyO and Lfb- 
MemsetC) routines in both linear and 
banked modes. The benchmark runs for 
ten seconds so dial any granularity in the 
system timer can be factored out. 
Shutdown restores VGA mode 3 (SO col¬ 
umn text mode) and finally computes and 
prints the results of the tests in both 
Mbytes/sec and frames/sec, 

DDj 
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Listing One (Text begins on page 35J 

/**************************************************************************** 

* VBE 2.0 Linear Framebuffer Profiler 

• By Kendall Bennett and Brian Hook 

* Filename: LFBPROF.C 

• Language: ANSI C 

* Environment: Watcom C/C++ 10.0a with D0S4GW 

• Description: Simple program to profile the speed of screen clearing 

* and full screen BitBlt operations using a VESA VBE 2.0 

• linear framebuffer from 32 bit protected mode. 

* For simplicity, this program only supports 256 color 

• SuperVGA video modes that support a linear framebuffer. 
*****************************************************************+*«******•«/ 

#include <stdio.h> 

♦include <stdlib.h> 

♦include <string.h> 

♦include <conio.h> 

♦include <do8.h> 

♦include "lfbprof.h" 


/*- 

int 

int 

int 

short 

float 

float 

float 

float 

int 

int 

long 

char 


VESABuf_len « 1024: 

VESABuf_sel = 0: 

VESABuf_rsea; 

modeList[50]: 

clearsPerSec; 

clearsMbPerSec; 

bitBltsPerSec: 

bitBltsMbPerSec; 

xres.yres; 

bytesperline: 

imageSize; 

far *LFBPtr; 


Global Variables - 

/* Length of VESABuf 
/♦ Selector for VESABuf 
/♦ Real mode segment of VESABuf 
/♦ List of available VBE modes 
/* Number of clears per second 
/♦ Memory transfer for clears 
/♦ Number of BitBlt's per second 
/* Memory transfer for bitblt's 
/♦ Video mode resolution 
/♦ Bytes per scanline for mode 
/♦ Length of the video image 
/* Pointer to linear framebuffer 


/•-DPMI interface routines — 


- */ 

•/ 

♦/ 

♦/ 

•/ 

•/ 

•/ 

*/ 

•/ 

•/ 

•/ 

*1 

•/ 

-•/ 


void DPMI_allocRealSeg(int size.int *sel.int ♦r_seg) 
/**************************************************************************** 

* Function: DPMI.allocRealSeg 

* Parameters: size - Size of memory block to allocate 

* sel - Place to return protected mode selector 

* r_seg - Place to return real mode segment 

* Description: Allocates a block of real mode memory using DPMI services. 

* This routine returns both a protected mode selector and 

* real mode segment for accessing the memory block. 
****************************************************************************/ 
C 

union REGS r: 


/• DPMI allocate DOS memory 
/• number of paragraphs 


r.w.ax = 0x100; 
r.w.bx = (size ♦ 0xF) » 4; 
int386(0x31, 6r. &r): 
if (r.w.cflag) 

FatalError("DPMI_ailocRealSeg failed!"): 

♦sel * r.v.dx; /♦ Protected mode selector 

♦r_seg * r.w.ax: /• Real mode segment 


♦/ 

♦/ 


♦/ 

•/ 


) 

void DPMI.freeRealSeg(unsigned sel) 

/**************************************************************************** 

♦ Function: DPMI.allocRealSeg 

♦ Parameters: sel - Protected mode selector of block to free 

♦ Description: Frees a block of real mode memory. 

*************** 9 ************************************************************/ 

c 

union REGS r: 


r.w.ax ■ 0x101: 
r.w.dx = sel: 
int3B6(0x31. &r. ir): 

) 

typedef struct { 


/♦ DPMI free DOS memory 
/* DX := selector from 0x100 


*/ 

♦/ 


long 

edi; 

long 

eai: 

long 

ebp; 

long 

reserved: 

long 

ebx; 

long 

edx: 

long 

ecx: 

long 

eax: 

short 

flags: 

short 

es,ds.fs.gs,ip.cs,sp.ss; 

) .RMREGS: 


♦define IN(reg) 
♦define OlTT(reg) 


rmregs.e##reg ■ in->x.reg 
out->x.reg = rmregs.e#*reg 


int DPMI_int86(int intno. RMREGS »in. RMREGS *out) 

/**************************************************************************** 

• Function: DPMI_int86 

• Parameters: intno - Interrupt number to issue 

• in Pointer to structure for input registers 

• out - Pointer to structure for output registers 

• Returns: Value returned by interrupt in AX 

• Description: Issues a real mode interrupt using DPMI services. 
****************************************************************************/ 
( 


.RMREGS 
union REGS 
struct SREGS 


rmregs: 


memset(6rmregs. 0. sizeof(rmregs)): 

IN(ax): IN(bx): IN(cx): IN(dx): IN(si); IN(di); 


segread(6sr): 
r.w.ax ■ 0x300: 
r.h.bl = intno: 
r.h.bh • 0: 
r.w.cx = 0: 


/♦ DPMI issue real interrupt 


sr.es a sr.ds; 

r.x.edi = (unsigned) irmregB: 
int386x(0x31. 6r. 6r. &sr): 


/♦ Issue the interrupt 


OUT(ax): OUT(bx): OUT(cx); OUT(dx); OUT(si); OUT(di); 
out->x.cflag = rmregs.flags & 0x1; 
return out->x.ax; 

) 

int DPMI_int86x(int intno. RMREGS *in, RMREGS *out, RMSREGS *sregs) 
/**************************************************************************** 


♦ Function: 

* Parameters: 


♦ Returns: 

♦ Description: 


DPMI_int86 
intno - Interrupt number to issue 
in - Pointer to structure for input registers 

out - Pointer to structure for output registers 

sregs - Values to load into segment registers 
Value returned by interrupt in AX 
Issues a real mode interrupt using DPMI services. 


.RMREGS 
union REGS 
struct SREGS 


rmregs: 

r; 

sr: 


memset(6rmregs. 0, sizeof(rmregs)): 

IN(ax): IN(bx); IN(cx); IN(dx): IN(si); IN(di): 
rmregs.es = sregs->es; 
rmregs.ds = sregs->ds: 


/* DPMI issue real interrupt 


/• Issue the interrupt */ 


•/ 


segread(4sr); 
r.w.ax = 0x300: 
r.h.bl * intno: 
r.h.bh 3 0: 
r.w.cx = 0; 
sr.es 3 sr.ds: 

r.x.edi = (unsigned)irmregs: 
int386x(0x31. &r. 4r. 6sr): 

OUT(ax); OUT(bx): OUT(cx): OOT(dx); OOT(si); OUT(di): 
sregs->es = rmregs.es: 
sregs->cs * rmregs.es: 

8 regs->8s = rmregs.ss: 
sregs->ds » rmregs.ds: 
out->x.cflag = rmregs.flags k 0x1: 
return out->x.ax; 

) 

int DPMI_allocSelector(void) 

/**»***m*****************t*************************************************** 

♦ Function: DPMI.allocSelector 

♦ Returns: Newly allocated protected mode selector 

♦ Description: Allocates a new protected mode selector using DPMI 

♦ services. This selector has a base address and limit of 0. 
****************************************************************************/ 
( 


int 

union REGS 


sel: 

r: 


r.w.ax » 0: 
r.w.cx = 1: 
int386(0x31. 6r. 6r): 
if (r.x.cflag) 

FatalError("DPMI.allocSelectorO failed!") 
sel e r.w.ax: 


/* DPMI allocate selector 
/♦ Allocate a single selector 


r.w.ax = 9: 
r.w.bx ■ sel: 
r.w.cx = 0x8092: 
Int386(0x31. &r. ir); 
return ael: 


/♦ DPMI set access rights 
/♦ 32 bit page granular 


♦/ 

♦/ 


*/ 

•/ 


long DPMI_mapPhysicalToLinear(long physAddr.long limit) 
/**********»***************************************************************** 


♦ Function: 

♦ Parameters: 

« 

♦ Returns: 

♦ Description: 


DPMI_mapPhysicalToLinear 

physAddr * Physical memory address to map 
limit - Length-1 of physical memory region to map 

Starting linear address for mapped memory 
Maps a section of physical memory into the linear address 

♦ space of a process using DPMI calls. Note that this linear 

♦ address cannot be used directly, but must be used as the 

♦ base address for a selector. 
*******************************************•*•***•**************************/ 
( 

union REGS r: 

r.w.ax ■ 0x800; /* DPMI map physical to linear •/ 

r.w.bx = physAddr >> 16: 

r.w.cx * physAddr 6 0xFFFF: 

r.w.si * limit » 16: 

r.w.di = limit 6 0xPFFF; 

int386(0x31. 6r. 6r): 

if (r.x.cflag) 

FatalError( n DPMI_mapPhysicalToLinear() failed!"); 
return ((long)r.w.bx << 16) + r.w.cx: 

) 

void DPMI_setSelectorBase(int sel.long linAddr) 
/*****♦**♦***♦♦******•***•****•***•**•*♦*••**••***•**•**••*#*•***••**••***•*♦ 

♦ Function: DPMI.setSelectorBase 

♦ Parameters: sel - Selector to change base address for 

♦ linAddr - Linear address used for new base address 

♦ Description: Seta the base address for the specified selector. 
****************************************************************************/ 
£ 

union REGS r: 


r.w.ax = 7; 

r.w.bx ■ sel: 

r.w.cx = linAddr >> 16: 

r.w.dx ■ linAddr & 0xFFFF; 

int386(0x31. 4r. &r): 

if (r.x.cflag) 


/* DPMI set selector base address */ 


(continued on page 40) 
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VESA 2.0 


Listing One (Listing continued , text begins on page 35) 


j 


FatalError("DPKI_setSelectorBase() failed!"): 


void DPMl.setSelectorLimit(int ael.long limit) 


* Function: DPMl.setSelectorLimit 

* Parameter®: sel - Selector to change limit for 

* limit - Limit-1 for the selector 

* Description: Sets the memory limit for the specified selector. 
**•****************************«********************************************/ 
{ 

union REGS r; 


r.v.ax = 8; /♦ DPMI set selector limit */ 

r.w.bx * sel; 

r.w.cx * limit >> 16: 

r.w.dx = limit 6 0xFFFF; 

int386(0x31, &r, &r); 

if (r.x.cflag) 

FatalError("DPMl.setSelectorLimit() failed!"); 

) 

/•-VBE Interface routines-«/ 

void FatalError(char •msg) 

{ 

fprintf(stderr. "*s\n", msg); 
exit(l): 

) 

static void ExitVBEBuf(void) 

{ 

DPMI.freeRealSeg(VESABuf.sel): 

) 

void VBE.initRMBuf(void) 

/***«***************************************************•***••*******••***••• 

* Function: VBE.initRMBuf 

* Description: Initialises the VBE transfer buffer in real mode memory. 

* This routine is called by the VESAVBE module every time 

* it needs to use the transfer buffer, so we simply allocate 

* it once and then return. 

****************************************************************••***•**•*••/ 

( 

if (IVESABuf.sel) ( 

DPMI_allocRealSeg(VESABuf_len, BVESABuf.sel. iVESABuf.rseg): 
atexit(ExitVBEBuf); 

) 

) 

void VBE.callESDI(RMREGS *regs. void *buffer. int size) 
/**************************************************************************** 

Function: VBE.callESDI 

Parameters: regs - Registers to load when calling VBE 

buffer - Buffer to copy VBE info block to 
size - Size of buffer to fill 

Description: Calls the VESA VBE and passes in a buffer for the VBE to 
store information in. which is then copied into the users 
buffer space. This works in protected mode as the buffer 
passed to the VESA VBE is allocated in conventional 
memory, and is then copied into the users memory block. 


RMSREGS sregs; 

VBE.initRMBuf(); 

8regs.es = VESABuf_rseg; 
regs->x.di » 0: 

.fmeracpy(MK.PP(VESABuf_sel.0).buffer.size)j 
DPMI.int86x(0xl0, regs. regs. isregs): 

_fmemcpy(buffer.MK_FP(VESABuf_ael.0).size); 

) 

int VBE.detect(void) 

• Function: VBE.detect 

* Parameters: vgalnfo - Place to store the VGA information block 

• Returns: VBE version number, or 0 if not detected. 

* Description: Detects if a VESA VBE is out there and functioning 

• correctly. If we detect a VBE interface we return the 

* VGAInfoBlock returned by the VBE and the VBE version number. 


) 


RMREGS regs; 

short •pl,*p2: 

VBE.vgalnfo vgalnfo; 

/* Put 'VBE2' into the signature area so that the VBE 2.0 BIOS knows 

• that we have passed a 512 byte extended block to it. and wish 

• the extended information to be filled in. 

•/ 

stmcpy(vgaInfo.VESASignature,"VBE2",4): 

/♦ Get the SuperVGA Information block ♦/ 
regs.x.ax = 0x4F00: 

VBE.callESDI(fiiregs, (.vgalnfo, sizeof (VBE.vgalnfo)); 
if (regs.x.ax != 0X004F) 
return 0: 

if (strncmp(vgalnfo.VESASignature,"VESA".4) != 0) 
return 0: 

/* Now that we have detected a VBE interface, copy the liat of available 

♦ video modes into our local buffer. We *must* copy this mode list, since 

* the VBE will build the mode list in the VBE.vgalnfo buffer that we have 

* passed, so the next call to the VBE will trash the list of modes. */ 
pi = LfbMapRealPointer(vgalnfo.VideoModePtr): 

p2 * modeList; 
while (*pl != -1) 

#p2++ = *pl-M-; 

•p2 = -i: 

return vgalnfo.VESAVersion; 


int VBB_getModeInfo(int mode.VBE.modelnfo *modelnfo) 
/«***•******•************•***•*******•****•***•**********•*****************•* 

* Function: VBE.getModelnfo 

* Parameters: mode - VBE mode to get information for 

* modelnfo - Place to store VBE mode information 

* Returns: 1 on success, 0 if function failed. 


Description: Obtains information about a specific video mode from the 
VBE. You should use this function to find the video mode 
you wish to set. as the new VBE 2.0 mode numbers may be 
completely arbitrary. 


RMREGS regs: 

regs.x.ax = 0x4F01: /* Get mode information */ 

regs.x.cx ■ mode; 

VBE.callESDI(Aregs, modelnfo, sizeof(VBE.raodelnfo)); 
if (regs.x.ax !■ 0X004F) 
return 0; 

if ((modelnfo->ModeAttributes 6 vbeMdAvailable) ■» 0) 
return 0: 
return 1; 

} 

void VBE_setVideoMode(int mode) 

/*..•.**..•*..**.•**.•**.•**..**•*•**«*..**•**..*»•.***.•**«.**.****•*•**,••. 

* Function: VBE.setVideoMode 

• Parameters: mode - VBE mode number to initialise 

********************«**************************•*********************•*****•/ 

C 

RMREGS regs; 
regs.x.ax = 0x4F02: 
regs.x.bx * mode; 

DPMI.intB6(0x10.iregs.iregs); 

) 

/* - Application specific routines -•/ 

void far »GetPtrToLFB(long physAddr) 


* Function: GetPtrToLPB 

* Parameters: physAddr - Physical memory address of linear framebuffer 

* Returns: Par pointer to the linear framebuffer memory 

*******•«*****••***************•••***••******••**••***•***«***«****••***••**/ 

{ 

int sel: 

long linAddr.limit « (4096 ♦ 1024) - t: 

sel = DPMI_allocSelector(): 

linAddr ■ DPMI.mapPhysicalToLinear(physAddr.limit): 

DPMI.setSelectorBase(sel.linAddr); 

DPMl.setSelectorLimit(sel.limit): 
return MK_FP(sel.0): 

) 

void AvailableModes(void) 

/**************************************************************************** 

* Function: AvailableModes 

* Description: Display a list of available LFB mode resolutions. 

c 

short *p; 

VBE.modelnfo nodeInfo: 


printf("Usage: I.FBPR0F <xres> <yres>\n\n"); 
printf("Available 256 color video modes:\n M ); 
for (p = modeList: *p != -1: p**) ( 

if (VBE. getModeInfo(*p. 4.modelnfo)) ( 

/• Filter out only 8 bit linear framebuffer inodes •/ 
if ((modelnfo.ModeAttributes & vbeMdLinear) “ 0) 
continue: 

if (modelnfo.MemoryModel !«* vbeMemPK 
!! modelnfo.BitsPerPixel !» 8 
SS modelnfo.NumberOfPlanes != 1) 
continue: 

printf(" %4d x %4d %d bits per pixel\n", 

modelnfo.XResolution. modelnfo.YResoiution. 
modelnfo.BitsPerPixel): 

) 

) 

exit(l); 


) 

void InitGraphicsUnt x.int y) 


/• 

* Function: 

* Parameters: 

* Description: 


InitGraphics 

x.y - Requested video mode resolution 
Initialise the specified video mode. We search through 
the list of available video modes for one that matches 
the resolution and color depth are are looking for. 


short *p: 

VBE.modelnfo modelnfo: 


/ 


for (p * modeList; »p I* -1: p++) ( 

if (VBE_getHodeInfo(*p. Smodelnfo)) ( 

/• Filter out only 8 bit linear framebuffer inodes */ 
if ((modelnfo.ModeAttributes 6 vbeMdLinear) ■« 0) 
continue: 

if (modelnfo.MemoryModel !■ vbeMemPK 
!! modelnfo.BitsPerPixel 1= 8 
!! modelnfo.NumberOfPlanes !» t) 
continue: 

if (modelnfo.XResolution !■ x !! modelnfo.YResoiution !■ y) 
continue; 
xres * x; 
yres * y: 

bytesperline = modelnfo.BytesPerScanLine; 
imageSize * bytesperline * yres; 

VBE.setVideoMode(*p ! vbeUseLFB): 

LFBPtr » GetPtrToLFB(modelnfo.PhysBasePtr); 
return; 

) 

) 

printf("Valid video mode not found\n"); 
exit(l): 

) 

void EndGraphics(void) 

/**************•*****************************************************«**♦**** 

* Function: EndGraphics 

* Description: Restores text mode. 
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RMREGS rega; 
regs.x.ax = 0x3: 

DPMI _inl86(0x10. 4regs, &regs): 

) 

void ProfileMode(void) 

... 

♦ Function: ProfileMode 

♦ Description: Profiles framebuffer performance for simple screen clearing 

♦ and for copying from system memory to video memory (BitBlt). 

♦ This routine thrashes the CPU cache by cycling through 

♦ enough system memory buffers to invalidate the entire CPU 

♦ external cache before re-using the first memory buffer again. 
**•*******»**♦***♦***♦*********•***•*************•**********•***************/ 
( 


int i.numClears,numBlts. raaxlmages: 

long startTicks.endTicks: 

void *image[10].*dst: 


/• Profile screen clearing operation */ 
startTicks = LfbGetTicksO: 
numClears = 0; 

while ({LfbGetTicksO - startTicks) < 182) 

LfbMemset (FP_SEG(LFBPtr) .0,numClears++. imageSize): 
endTicks ■ LfbGetTicksO; 

clearsPerSec = numClears / ((endTicks - startTicks) * 0.054925): 
clearsMbPerSec * (clearsPerSec * imageSize) / 1048576.0; 


/* Profile system memory to video memory copies */ 
maxImageB = ((512 ♦ 1024U) / imageSize) + 2: 
for (i * 0; i < maxlmages; i++) { 
image[i] = malloc(imageSize): 
if (image [i] « MULL) 

FatalError("Mot enough memory to profile BitBlt!"); 
memset(imaged],i+1, imageSize): 

) 

startTicks ■ LfbGetTicksO; 
numBlts = 0: 

while ((LfbGetTicksO - startTicks) < 182) 

LfbMe»cpy(FP_SEG(LFBPtr).0.image[numBlts++ % maxlmages].imageSize): 
endTicks « LfbGetTicksO; 

bitBltsPerSec * numBlts / ((endTicks - startTicks) • 0.054925): 
bitBltsMbPerSec = (bitBltsPerSec ♦ imageSize) / 1048576.0: 

) 

void maindnt argc. char *argv(]) 

( 

if (VBE.detectO < 0x200) 

FatalError("This program requires VBE 2.0: Please install UniVBE 5.1."); 


if (argc != 3) 

AvailablcModes0; /* Display available modes */ 

InitGraphics(atoi(argv(1]).atoi(argv[2])): /* Start graphics ♦/ 

ProfileKodeO : /• Profile the video mode */ 

EndGraphics(); /* Restore text mode */ 


printf("Profiling results for tdx%d 8 bits per pixel.\n",xres,yree); 
printf("*3.2f clears/s. %2.2f Mb/s\n". clearsPerSec. clearsMbPerSec): 
printf("%3,2f bilBIt/s. %2.2f Mb/s\n". bitBltsPerSec, bitBltsMbPerSoc): 


Listing Two 


/I!*************************************************************************** 

♦ VBE 2.0 Linear Framebuffer Profiler 

♦ By Kendall Bennett and Brian Hook 

<• Filename: LFBPROF. H 

• Language: ANSI C 

* Environment: Watcom C/C++ 10.0a with D0S4GW 

• Description: Header file for the LFBPROF.C progam. 

tc**************************************************************************/ 


Macros and type definitions-*/ 


/• 'VESA' 4 byte signature */ 
/• VBE version number •/ 
/* Pointer to OEM string ♦/ 
/• Capabilities of video card */ 
/* Pointer to supported modes */ 
/* Number of 64kb memory blocks */ 


♦ifndef ..LFBPROF Ji 
♦define LFBPROF_H 

♦pragma pack(l) 

/* SuperVGA information block ♦/ 
typedef struct ( 


char 

VESASignature[4]; 

short 

VESAVersion; 

long 

OemStringPtr; 

long 

Capabilities; 

long 

VideoModePtr; 

short 

TotalMemory: 

l* VBE 

2.0 extensions */ 

short 

OemSoftwareRev: 

long 

OemVendorNamePtr; 

long 

OemProductName Ptr 

long 

OemProductRevPtr; 

char 

reserved[222]; 

char 

0emDATA[256]: 

} VBE.vgalnfo: 


/* OEM.Software revision number */ 
/* Pointer to Vendor Name string +/ 
/♦ Pointer to Product Name string */ 
/* Pointer to Product Revision str */ 
/♦ Pad to 256 byte block size */ 
/* Scratch pad for OEM data */ 


/* SuperVGA mode information block •/ 
typedef struct { 


short 

ModeAttributes: 

/♦ Mode attributes 

♦/ 

char 

WinAAttributes; 

/* Window A attributes 

*/ 

char 

WinBAttributes; 

/♦ Window B attributes 

•/ 

short 

WinGranularity; 

/* Window granularity in k 

•/ 

short 

WinSize; 

/♦ Window size in k 

•/ 

short 

WinASegment; 

/* Window A segment 

*/ 

short 

WinBSegment; 

/• Window B segment 

•/ 

long 

WinFuncPtr: 

/* Pointer to window function 

*/ 

short 

BytesPerScanLine: 

/♦ Bytes per scanline 

•/ 

short 

XResolution; 

/* Horizontal resolution 

*/ 

short 

YResolution: 

/• Vertical resolution 

•/ 

char 

XCharSize; 

/* Character cell width 

*/ 


char 

YCharSize: 

/+ 

char 

NumberOfPlanes; 

/* 

char 

BitsPerPixel: 

/• 

char 

NumberOfBanks; 

/* 

char 

MemoryModel: 

/♦ 

char 

BankSize; 

/♦ 

char 

NumberOflmagePages; 

/♦ 

char 

real; 

/* 

char 

RedMaskSize: 

/♦ 

char 

RedFieldPosition; 

!* 

char 

GreenMaskSize: 

/* 

char 

GreenFie1dPosition; 

/* 

char 

BlueMaskSize; 

/• 

char 

BlueFieldPosition; 

/* 

char 

RsvdMaskSize; 

/• 

char 

RsvdFieldPasitian: 

h 

char 

DirectColorModelnfo: 

/<* 


Character cell height */ 
Number of memory planes */ 
Bits per pixel •/ 
Number of CGA style banks */ 
Memory model type •/ 
Size of CGA style banks */ 
Number of images pages •/ 
Reserved */ 
Size of direct color red mask •/ 
Bit posn of Isb of red mask */ 
Size of direct color green mask •/ 
Bit posn of lsb of green mask */ 
Size of direct color blue mask •/ 
Bit posn of lsb of blue mask */ 
Size of direct color res mask •/ 
Bit posn of lsb of res mask */ 
Direct color mode attributes *t 


/* VBE 2.0 extensions */ 
long PhysBasePt r: 

long OffScreenMenOffset; 

short OffScreenMemSize; 

char res2[206]; 

) VBE.modelnfo: 

♦define vbeMemPK 4 

♦define vbeUseLFH 0x4000 


/* Physical address for linear buf */ 
/* Pointer to start of offscreen mem*/ 
/» Amount of offscreen mem in IK's */ 
/• Pad to 256 byte block size */ 

/• Packed Pixel memory model ♦/ 
/• Enable linear framebuffer mode ♦/ 


/• Flags for the mode attributes returned by VBE_getModeInfo. If 

* vbeMdNonBanked is set to 1 and vbeMdLincar is also set to 1. then only 

• the linear framebuffer mode is available. */ 


♦define vbeMdAvailable 0x0001 /* Video mode is available */ 
♦define vbeMdColorMode 0x0008 /* Mode is a color video mode */ 
♦define vbeMdGraphMode 0x0010 /* Mode is a graphics mode •/ 
♦define vbeMdNonBanked 0x0040 /* Banked mode is not supported •/ 
♦define vbeMdLinear 0x0080 /• Linear mode supported •/ 


/* Structures for issuing real mode interrupts with DPMI */ 
struct .RMWORDREGS ( 

unsigned short ax, bx, cx, dx, si. di. cflag: 

1 : 

struct -RMBYTEREGS ( 

unsigned char al. ah. bl, bh, cl, ch. dl. dh; 

); 

typedef union ( 

struct RMWORDREGS x; 
struct .RMBYTEREGS h: 

) RMREGS; 
typedef struct [ 

unsigned short es; 
unsigned short cs; 
unsigned short ss; 
unsigned short ds; 

) RMSREGS; 

/* Inline assembler block fill/move routines «/ 
void LfbMemset(int sel.int off.int c.int n)j 
♦pragma aux LfbMemset * \ 


"push 

es" 

\ 

"mov 

es.ax" 

\ 

"shr 

ecx.2" 

\ 

"xor 

eax.eax" 

\ 

"mov 

al.bl" 

\ 

"shl 

ebx.B" 

\ 

"or 

ax.bx" 

\ 

"mov 

ebx,eax" 

\ 

"shl 

ebx.16" 

\ 

"or 

eax.ebx" 

\ 

"rep 

stosd" 

\ 

"pop 

parm 

[eax] [edi] [ebx] [ecx]: 

\ 


void LfbMemcpy(int sel.int off.void *src.int n): 


♦pragma aux LfbMemcpy = \ 

"push es" \ 

"mov es.ax" \ 

"shr ecx.2" \ 

"rep moved" \ 

"pop es" \ 


parm [eax] [edi] [esi] [ecx]; 


/* Map a real mode pointer into address space •/ 

♦define LfbMapRealPointer(p) (void*)(((unsigned)(p) » 12) ♦ ((p) & 0xFFFF)) 

/• Get the current timer tick count */ 

•define LfbGetTicksO *((long*)0x46C) 


•pragma pack() 

•endif /♦ __LFBPROF_H */ 


Listing Three 


I Very simple makefile for LFBPRQP.C using Watcom C++- 10.0a with D0S4GW 

lfbprof.exe: lfbprof.c lfbprof.h 
wcl386 -zq -s -d2 lfbprof.c 

End Listings 
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WING & WAVEMIX 


Implementing Games 
for Windows 


t first glance, it seems that Win¬ 
dows, with its graphical nature, 
device independence, access to 
boatloads of memory* and various 
levels of multitasking, would be 
a perfect environment for games. But game 1 
developers have not been Hocking to Wind jws* 
To improve Windows’ video and sound 
performance, Microsoft released two APIs: 
WinG and WaveMix, both of which are avail¬ 
able for fee on CompuServe (GO W1NMM 
LiB 10) and the Internet (ftp.microsoft.com). 
WinG provides high-performance, device¬ 
independent graphics capabilities in the 
form of DLLs and a GDI device driver. 
WaveMix, is a DLL that lets you mix sound 
files or resources into a single sound output 
at inn time and* optionally, to hook sounds 
up to events within your application* 

In this article, I’ll review some traditional 
PC game-animation techniques and show 
bow WinG can be used to implement 
them in Windows* 1 11 also use both 
WinG and WaveMix in an applica¬ 
tion allied \X inGTestf which should 
give you enough of a foundation to 
start working with these APIs on your 
own. You'll see that together, these 
APIs let you develop powerful games 
and other multimedia apps, 

Gome Animation 

Most game animation implemented 
on PCs and video games is cast based, 
whereby a game player actively ma¬ 
nipulates movable screen objects 
(members of the cast). This differs 

James is a developer specializing in 
operating-systems internals* He can 
be reached at P.O. Box 436, Fal¬ 
mouth , MA 02541 or tia Internet at 
FINNEGANJ@delphi.com . Reprinted 
courtesy of Microsoft Systems Journal 
©1995 Miller Freeman, 


Using the WinG 
API and the 
WaveMix DLL 


James Finnegan 


from frame-based animation, as in a Video 
for W indows AVI dip, where precomposed 
full-screen images are animated. 

Tlie movable screen objects in cast-based 
animations, commonly referred to as 
‘sprites," are bitmapped images that are 
usually animated against a background im¬ 
age to add realism. Any developer who lias 
tried to implement tliis type of animation 



know s that getting visually acceptable re¬ 
sults (smooth, flicker-free sprite movement) 
requires quite a bit of w r ork. 

On dedicated home and coin-operated 
video games (and some computers), spe¬ 
cialized hardware is used to implement 
sprite animation. This makes the program¬ 
mers job easier, since less knowledge of a 
particular animation technique is required 
to move an object from place to place. 

On PCs, specialized sprite-animation 
hardware is generally not at your dispos¬ 
al* You therefore have to roll your own rou¬ 
tines to continually place an object on lire 
screen, remove it, and place it at a new r lo¬ 
cation. Under DOS, direct access to the 
video adapter's memory and access to the 
adapter s controller registers gave you ex¬ 
plicit control over various attributes and 
operations of the adapter (such as its palette 
of colors), enough control to implement 
your own animation routines. 

With direct access to the pixels 
that make up the screen image, you 
had to build routines that manipu¬ 
lated these pixels to implement 
sprite animation. These routines 
were necessary to “hide” the re¬ 
moval and replacement of an ani¬ 
mated sprite, which would other¬ 
wise create flicker, Typically, one of 
three different animation techniques 
w'as used: XORing, page flipping, 
and double buffering. 

XOR animation involves writing a 
sprite directly to the video adapter's 
memory by XORing the source (the 
.sprite) and die destination (the mem¬ 
ory that makes up die screen). Re¬ 
moving the sprite is simply a matter 
of XORing the same image in the 
same place. Doing this successively 
gives you sprite animation. Since the 
video adapter’s memory is being ac¬ 
cessed directly, the on-screen results 
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are virtually instantaneous. However this 
method only works against a solid back¬ 
ground, since the XORing alters, rather 
than hides, any background scene that die 
sprite is placed over. 

Page lipping involves dividing the video 
adapter's memory into two or more 
“pages,” where a page represents an en¬ 
tile screenful of graphics. While one page 
is being displayed, another page is being 
constructed. When the page is ready or 
when a certain amount of time has 
elapsed, the visible and hidden pages are 
Swapped by altering the graphics base ad¬ 
dress of the video adapter. Since the 
screen is continually being refreshed, 
changing the memory address results in 
the display changing. 

The tliird technique is double-buffering, 
in which an application-managed buffer Is 
used to construct the screen image. When 
the buffer is complete, the image (or a por¬ 
tion of it) is copied to the video adapter's 
memory (which directly defines die screen 
image), updating the display accordingly. 
This is conceptually similar to page hip¬ 
ping, except die performance is somewhat 
different, since memory is being copied en 
masse to the display hardware. 

All of this direct hardware access trades 
device independence for raw performance. 
Although this was acceptable under DOS, 
it isn’t under Windows, where device in¬ 
dependence, rather than specific hardware 
access, yields broad compatibility. 

Memory Woes 

As if direct hardware access isn’t bad 
enough, games have another hurdle to 
overcome. Graphics of any kind usually 
hog memory. Bitmapped images tend to 
be large, and the recent demands for in¬ 
creased screen resolution, with increased 
game complexity, don't help the situation 
much (particularly when dealing with 
DOS). People have traditionally addressed 
the problem of increased memory de¬ 
mands with DOS extenders. 

Windows has gained acceptance as a 
replacement platform for DOS for busi¬ 
ness applications. Unfortunately, this has 
not been the case with games. 

The two key concerns facing PC game 
developers are: providing smooth, fast ani¬ 
mation, and access to a lot of memory . 
Memory management is easy in Windows* 
It is the graphics performance—particu¬ 
larly when trying to implement animation 
routines—that is die problem. 

Even though Windows offers high-level 
graphics primitives through GDI, it is not 
well suited for high-performance anima¬ 
tion. This is largely because of Windows 
device independence. To support differ¬ 
ent hardware in a consistent manner, you 
need device drivers. This means two 
things: First, the device driver has to do 


something to convert a generic function 
into something device specific. That extra 
code takes time to execute. Second, your 
application’s performance is at the mercy 
of tho.se device drivers. Even though some 
device drivers stink, their poor perfor¬ 
mance often goes unnoticed on machines 
running only business applications. 

For animation, particularly with games, 
extra code and poor performance are en¬ 
emies. Combine that with Windows' lack 
of flexibility drawing display contexts (you 
can only use GDI functions), and Win¬ 
dows seems like a bad choice for games. 

Even if GDI and its device drivers per¬ 
formed exceedingly well, the functions 
Windows offers are not always appropri¬ 
ate for all types of graphics. For instance, 
GDI does no 3-D transformations. Nor 
does it do anything specific for anima¬ 
tion. Good or bad, the direct memory ac¬ 
cess that DOS provided to developers 
yielded a huge number of software-based 
graphics solutions. 

DIBs versus DDBs 

Windows 3.0 introduced the device inde¬ 
pendent bitmap (DIB) to address bitmap 
portability issues, A DIB defines a bitmap’s 
dimension, colors, and pixels in a single 
structure. Since the characteristics of a DIB 
are self encapsulated, rendering it on dif¬ 
ferent devices usually yields visually com¬ 
parable results. In addition, you have com¬ 
plete access to the entire DIB, which 
means that you can fool with anything, in¬ 
cluding the pixels that make up its bitmap, 
at will. 

The GDI API, however* deals with 
device dependent bitmaps (DDBs) that 
are represented by a device context (DC), 
which GDJ uses to do most of its manip¬ 
ulations. This means anything you want 
to do to a DDB must be done through 
GDI. This is primarily because the DC is 
allocated and maintained by the output 
device’s device driver. The memory used 
to define an image, particularly with video 
and printer drivers, may be physically 
inaccessible to your application. In addi¬ 
tion, particularly with video drivers, the 
image may not be stored contiguously, or 
in a format that you can determine. For 
example, some video adapters divide up 
their memory into bit planes, where the 
bits that make up the pixels are divided 
into individual color values and stored sep¬ 
arately. This is done for quicker access 
within the physical memory frame that the 
video adapter uses. Other video adapters 
use a packed-pixel format (where pixels 
are stored linearly, much like a DIB). Ma¬ 
nipulating foe DDB without the aid of GDI 
(really the device driver) is not possible. 

In short, you have the DIB, which you 
can fool w ith any way you want, and die 
DDB. w hich Windows manipulates. There 


is little “glue” in between. For instance, 
there are GDI functions that move a DIB 
to a DC: however, they perform poorly 
and inconsistently across some device 
drivers. In addition, there is no way to call 
GDI functions, such as Ellipse or Polygon , 
to manipulate the DIB at a higher level. 

To alleviate the latter problem, Win¬ 
dows 3.1 ships with DIB.DRV, a GDI de¬ 
vice driver with no associated output de¬ 
vice. To GDI, DIB,DRV looks just like 
another output device. This driver allows 
you to allocate a DIB and create a mem¬ 
ory DC to go with it, so you can manip¬ 
ulate the DIB directly w hile still manipu¬ 
lating it with GDI function calls. 

Although DIB.DRV Ls useful, it does not 
help move a DIB to the display easily and 
quickly. You may think that since DIB.DEV 
allows you to associate a DC to a DIB, you 
could call GDIs BifBIt to move the bitmap 
from one DC to the other, but the actual 
BifBIt function is implemented in the de¬ 
vice driver, not GDI. Thus, the video driv¬ 
er’s BiiBlt can only copy from DCs that it 
knows; DIB.DRV's DCs are not among 
them. You are then left to contend with 
StretcbDLBits. If StretchDIBits is not imple¬ 
mented in the device driver, GDI will fake 
it by calling SetBitmapBits and Stretch Bit 
Needless to say, this results in inconsistent 
performance across different hardware. 

Enter WinG 

What you really need is DIB flexibility 
(with DlB.DRV-like functionality as a 
bonus), with the speed of the DDB Bit- 
Bit WinG 0 L G” for games) provides that 
and more. The WinG toolkit provides ac¬ 
cess to a DIB, which provides DOS-like 
double-buffering flexibility in a device- 
independent fashion. Using WinG, your 
app copies foe DIB to the screen .so quick¬ 
ly that you get DOS-like performance on 
most hardware, 

WinG offers a number of advantages 
over programming in DOS. First, Windows 
offers all of tile memory benefits of a DOS 
extender and more. Second, video-device 
Independence lets you consistently access 
resolutions higher than those under DOS, 

DOS games usually have to take a 
lowest- common-denominator approach 
to video graphics* so that most DOS games 
rarely go beyond VGA’s standard mode 
X (the “undocumented” 320x240x256 
mode used in many games). To fill all of 
that new-found screen real estate* WinG 
offers fast Bit stretching. 

WinG gives you direct-access perfor¬ 
mance by utilizing the best path to your 
hardware. To determine which path will 
be used, WinG analyzes your PC upon in¬ 
stallation, If WinG recognizes your hard¬ 
ware (as a video chipset from one of 
about eight different manufacturers, such 
as Tseng La Ids and Western Digital), i t will 
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obtain a pointer directly to the video 
graphics memory (traditionally at A000), 
which it will write to. WinG obtains tills 
pointer by employing DVA.386, the VFlatD 
device, which creates a selector to this 
memory address. In the future, this inter¬ 
face will be replaced by the Display Con¬ 
trol Interface (Dp), which is designed to 
supply a consistent method of obtaining 
the video memory pointer (among other 
things) for use by APIs like WinG. 

WinGBitBIt and WinGStretchBlt exist 
only to get your bits from the DIB to the 
screen. In the absence of a known video 
card, the WinG profiler times the various 
ways to get bitmaps of different sizes to 
the screen. It determines whether a top- 
down or bottom-up DIB rendering Is bet¬ 
ter. For each case, WinG will use the 
fastest combination of GDI functions and 
driver calls. On some cards this might in¬ 
volve using direct video access (DVA.386); 
on others StretcbDIBits is optimized for 
pipelined data transfer to the video card. 
WinG doesn’t care; the fastest road is the 
right one. These results, along with the 
current video driver’s name and version 
number, are stored in a setting within your 
Windows configuration (WIN.INI under 
Windows 3.1) information. This perfor¬ 
mance analysis is done at installation time, 
and is only performed again if the video 
driver or its version changes. 

The WinG API 

Fortunately, the actual run-time configu¬ 
ration is largely hidden in a small, device- 
independent API. This API Is conceptual¬ 
ly similar to DIB.DRV, but unlike DIB.DRV, 
it includes a high-level BitBlt routine to 
quickly copy DIBs to a given display DC. 
This optimized BitBlt function, called 
WinGBitBIt , is the core of WinG. 

The WinG AIM also includes two functions 
for implementing a lialftone palette. This type 
of palette selects a set of colors that will 
emulate 24-bit true color in an 8-bit, 256-cd- 
or device. See Appendix A of “Writing HOT 
Games for Microsoft Windows” included 
on the FIT server in GAMESUM.ZIP, for a 
detailed description of each API. 

Despite till these features (and its name), 
WinG isn’t a high-level gaming API. Things 
such as bitmap animation or collision de¬ 
tecting are not part of WinG. This keeps 
WinG (much like DOS) from being tied 
to a particular animation method. For in¬ 
stance, many games are 2-D, while oth¬ 
ers (like Atari’s Marble Madness ) are iso¬ 
metric (2-D with a 3-D-like background— 
a form of fake 3-D), while still others ( like 
id’s DOOM ) are true 3-D, with translation 
and scaling of objects in a 3-D scene. 
Since many of these types of routines have 
already been developed for DOS applica- 
tioas, porting these techniques to WinG 
is relatively easy. 


Unfortunately, WinG lacks some rou¬ 
tines that jast about all games need. For 
iastance, the routine to copy a sprite with 
a transparent color (since bitmaps are rect¬ 
angular by definition, a transparent color 
allows you to display arbitrarily shaped 
sprites) is not part of WinG. DIB-oriented 
manipulation functions are also absent. 
However, many of these routines are in¬ 
cluded with the WinG sample applica¬ 
tions, so you can just cut and paste. 

WinG implements a double-buffering 
scheme, so techniques such as page flip¬ 
ping cannot be implemented. I Tils is not a 
big deal, since page flipping and buffering 
are very similar. Their differences under DOS 
have to do only with performance issues. 
Porting existing page-flipping code shouldn’t 
be difficult. Sometliing similar to page flip¬ 
ping will be available (in a device-inde¬ 
pendent form) in DCI, although this most 
likely will be hidden behind the WinG API. 

Of course, you can’t access low r -level 
video registers under WinG either. You 
really shouldn’t need to, since most ac¬ 
cess has to do with direct palette manip¬ 
ulation, changing memory base address¬ 
es, and so on, none of which have to be 
done with WinG. These limitations are 
only a concern if you are doing a straight 
port from DOS. WinG does not include 
any timer-oriented functions, but these are 
supplied by other parts of Windows. For 
instance, the multimedia API supplies 
many of the preemptive timer functions 
that you would need to implement games. 
Also, WinG has no support for sound. 

32-Bit Hacking 

One important note: WING.DLL and 
WINGDE.DLL contain highly optimized, 
32-bit code. Examination of either of these 
two DLLs with the EXEHDR utility shows 
dial many of their code segments are 32 
bit. This is great for performance, but you 
may wonder how' it is done. For instance, 
if you could do the same in your WinG 
code for critical functions, performance 
might improve significantly. 'Hie secret Is 
hidden within CMACR032.INC, included 
on the MSDN CD and in the WinG-toolkit 
samples. When you create an assembly 
function using the cProc macro, the code 
in Example 1(a) is placed at the begin¬ 
ning of your function. 

Sixteen-bit Windows ignores the 32-bit 
segment flag that EXEHDR sees, which 
meaas that the code segment is loaded as 
a 16-bit segment. When AX is added to it¬ 
self, the carry flag is set. The jumped-to 
code looks like Example 1(b). This sets 
the descriptor in the LDT to USE32, caus¬ 
ing the prologue code in Example 1(b) to 
be interpreted as Example 1(c). 

The LDT hacking code is not called 
again unless the code segment is discard¬ 
ed and reloaded by Windows. The cEnd 


macro overrides the RETF instruction with 
the operand override (66H) byte. You 
must set the linker option “/NOPACK- 
CODE” for this to work successfully. If the 
USE32 object File is packed with your 16- 
bit C or C++ functions, the LDT hacking 
would mess up your 16-bit code: Usual¬ 
ly, your application will GP fault after re¬ 
turning from the called 32-bit function. 

Getting to Work 

Developing a game of any type is fairly 
complex. Collision sensing, keeping tabs 
on all those screen images and their states, 
rotation and translation of sprites, and the 
like are pretty involved. To keep tilings 
simple, I’ll present a sprite-animation pro¬ 
gram called “WinGTest,” which demon¬ 
strates how to construct WinG DCs, as¬ 
sociate bitmaps to the DCS, and shuttle 
data between DIBS, WinG DCs, and the 
display DC. The program (available elec¬ 
tronically, see “Availability,” page 3) al¬ 
lows users to drag a sprite across a back¬ 
ground with the mouse, updating the 
off-screen buffer and ultimately the screen 
as needed. WinGTest is made up of two 
modules: WINGTEST.C and IJTILS.C, 
which is sample code included with the 
WinG SDK for DIB manipulation. Re¬ 
viewing its axle should give enough clues 
to get you started on your own animated 
game projects. 

The first thing to do is pull together 
your DIBS. In my example, I load three 
DIBS, one for the window background, 
and the other two for sprites. I use the 
DibOpenFile function from IJTILS.C. Dib- 


(a) 

xor ax,ax 
mov ah.80h 

add ax. ax ;;Will o/flow in 16 bits 
jc short &n&_fix_cs 

(b) 

mov bx.cs 

mov es.ax 
mov di.sp 
mov ax,000Bh 

int 31h ;;; DPMI: Get the CS descr 
;:; change the following to USE32 
or byte ptr es:[di+6],40h 
mov ax,000Ch 

int 31h ;;; DPMI. Set the CS descr 

(c) 

xor eax.eax 
mov ah,80h 

add eax.eax ;; Doesn't overflow in 

32 bits 

jc short &n&_fix_cs 


Example 1: (a) Function header 
generated by cProc macro; 

(b) jumped-to from header, sets the 
CS descriptor in the LDT; (c) the 
header in (a) effectii>ely becomes this. 
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OpenFile will load either a disk file or an 
embedded resource, returning a pointer 
to the loaded DIB’s BITMAPINFOHEAD- 
ER structure. UTILS.II defines this struc¬ 
ture as a PDIB, which it uses in other API 
calls and macros to extract relevant infor¬ 
mation for you. 

The next step is the actual creation of 
the WinG DIB and its associated DC. Here 
you determine the best DIB format (top 
down or bottom up), as well as the iden¬ 
tity palette for your application. I have 
placed this code within the processing of 
my WMJ3IZE message, so I can dynami¬ 
cally resize the WinG DIB accordingly. 
For the mast part, the DIB orientation is 
not tremendously important to you; it is 
there if' you need to know (in case you 
are implementing your own bitmap- 
manipulation functions). The WinG-API 
calls hide die bitmap orientation from you. 

The first function to call is WinGRec- 
ommendDIBFormat; see Example 2(a). 
This function takes a pointer to a BITMAP- 
HEADERINFO structure and returns the 
optimal format for the Bit Bit mg DIBs to 
your display's DC. This information as¬ 
sumes that you wont be stretching or us¬ 
ing complex dipping regions, and that 
you will be using an identity palette. 


The only interesting bit of information 
returned is the DIB orientation. The hi- 
Height member of the BITMAP INFO- 
HEADER structure will be 1 if the DIB 
should be in a top-down format; other¬ 
wise, this field will be -1 to indicate a 
bottom-up format. In the future, the biBit- 
Count member will indicate the bits per 
pixel for the output device. Keep in mind 
that, for now, this field will only be 8, since 
this version of WinG only supports 8-bit, 
256-color output devices. For longer-terra 
compatibility and optimal performance, 
you will want to check this field and deal 
with it accordingly. 

Tire next step is the creation of the iden¬ 
tity palette. Windows reserves 20 colors 
within the 256-color palette for system- 
wide static colors. These colors include 
die colors for title bars, push buttons, win¬ 
dow frames, and so on. These colors take 
up the first and last ten entries of the 
palette. They are placed on either end so 
each can be XORed with its complement 
to allow inversion. To be as friendly as 
possible to other applications, you should 
leave these 20 colors in place. That leaves 
236. If you need more colors, you can get 
254 of the 256 (black and white cannot be 
taken) by calling GDI's SetSysiemPaletteUse 


with SYSPAL_NOSTATJC, although this can 
make other applications ugly. If you do 
this, I recommend that you make your 
games full-screen to hide the hideous 
screen colors. 

Once you have a suitable palette with¬ 
in a DIB, simply load the 236 colors into 
an array of PALETTEENTRY structures; see 
Example 2(b), 

To create the identity palette, each col¬ 
or should be flagged as PC_NOCOI1APSE 
(or PC_RESERVED, if you are going to be 
doing any palette animation). This will 
keep tire palette manager from combin¬ 
ing identical colors into one entry. The 20 
system colors should also be derived at 
run time and saved in their appropriate 
places, since the display driver determines 
these colors (they are not fixed across all 
platforms); see Example 2(c), Once all 256 
colors are in place, the palette can be cre¬ 
ated as in Example 2(d). This palette can 
then be selected and realized to the win¬ 
dow’s DC, just like any other GDI palette; 
see Example 2(e). 

This code is called in various places to 
ensure that the identity palette Is realized 
whenever the application is in the fore¬ 
ground. 

WinG DCs 

In a typical WinG application, you would 
create a single WinG DC, which you 
would use as your off-screen buffer. In 
my example, I will create two. One is for 
my background bitmap, which 1 will 
stretch into the DC using standard GDI 
calls. I am using this DC as a buffer so 1 
can quickly restore my background when 
a sprite is moved. The second WinG DC 
is for my off-screen buffer, which I will 
use to create the image that will be Med 
to the display. 

My first WinG DC is created by calling 
WinGCreate(X see Example 3(a). I then 
create a bitmap using the WinGCre- 
ateBitmap call. The dimensions of the 
bitmap are contained within WinGDIB- 
Header, as in Example 3(b). Hus function 
returns a DDB HBITMAP for use with GDI 
calls, as well as a live pointer to the 
bitmap’s actual bits. I place this value in a 
huge pointer to seamlessly allow access to 
bitmaps larger than 64 Kbytes. This huge 
pointer can subsequently be used either 
in assembler as an FWORD (16:32) point¬ 
er or with the C run-time library calls that 
support it. The new bitmap is then selected 
into the WinG DC; see Example 3(c). 

Finally, die bitmap loaded at the start 
of this program is stretched to fill the DC. 
Like all GDI devices, this standard GDI 
call is actually implemented by the device 
driver, WING DIB. DRV. As you will see, 
when working within WinG, you can still 
rely on a few familiar GDI calls. I’ve used 
these GDI calls for expediency. You may 


(a) 

WinGRec own e n dDIEFormat((BITMAPINFO far*)&WinGDIBHeader.bmiHeader); 

(b) 

for(iColorlndex = 10:iColorlndex < 246;iColorIndex++) 
t 

WinGDIBHeader.bmiCoIors[iColorlndex].rgbRed = 

LogicalPalette.palEntries[iColorlndex].peRed * 
pColorTable[icolorlndex].rgbRed; 

WinGDIBHeader,bmiCoiors[iColorlndexl,rgbGreen = 

LogicalPalette. palEntrlea [iColorlndex] .peGreen = 
pColorTable[iColorlndex].rgbGreen: 

WinGDIBHeader,braiColors [iColorlndex].rgbBlue = 

LogicalPdlette.paLEntries[iColorlndex],peBlue ® 
pColorTable[ieolorlndexl.rgbBlue; 

WinGDIBHeader♦bmiColors[!Colorlnd exj,rgbReserved = 0; 

// This flag includes PC_N0C0LLAP5E 

LogicalPalette.palEntriea[iColorlndexl.peFlags - 

PC.RESERVED; 

1 

(C) 

// Get the 20 static colors 

hDC = GetDC(G): 

GetSystemPaletteEntries(hDC,0,10.LogicalPalette.palEntries); 

GetEystemPaletteEntries(hDC,246,10.LogicalPalette.palEntries + 246): 

ReleaseDC£0,hDC): 

(d) 

ghMSJIdentityPalette ” CreatePalette((LGGPALETTE far*) 

^LogicalPalette): 

(G) 

5 electPalette(hDC,ghMSJldentity?alette,FALSE); 

RealizeFalette(hDC); 


Example 2: (a) Function prototype for WinGRecornmendDIBFormat; 

(b) loading 236 colors into an array of PALE11LENTRY structures; (c) sat/ing 
the 20 system colors; (d) creating the palette; (e) selecting the palette. 
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WING & WAVEMIX 


have more stringent performance re¬ 
quirements, in which case you should roll 
your ow n BitBltlng routine to copy source 
to destination DIBS. Be aware that WinG 
Ls not considered a palette device to GDI. 
That’s why DIB_RGB_ COLORS is used 
for the index parameter. Also note the 
use of the UTILS.C functions here. The 
DibXxv functions are all implemented in 
Example 3(d). I am stretching the bitmap 
once here so that I can use BitBlt to 
quickly copy portions of it later. The same 
thing is done for the double buffer that 
will be used for constructing the screen 
image, as in Example 3(e). 

After creating the double buffer, the en¬ 
tire background image is copied in; see 
Example 3(f). Once again, a standard GDI 
function is used. This is also implement¬ 
ed in WINGD1B.DRV. Be aware that many 
of these GDI functioas only work lietween 
DCs of the same type. In other words, 
WINGDIB.DRV’s BitBlt function cannot 
be used to BitBlt to a printer or to the 
screen. 

Within the WM_PAINT message pro¬ 
cessing, the offscreen buffer is copied to 
the window through a call to WinGBitBlt ; 
see Example 3(g). 

WinGBitBlt currently copies only from 
WinG DCs to display DCs. The identity 
palette is selected and realized again, for 
safety’s sake. If the palette is already re¬ 
alized, these functioas have very little over¬ 
head. With the identity palette in place, 
WinGBitBlt copies the DIB to the win¬ 
dow quickly, as quickly as a BitBlt using 
a DDB. 

WinG Wrap-Up 

Even though WinG is billed as an API for 
the future, it does not support DCI. This 
is not a big deal yet. If you stick to the 
WinG API now, you are likely to get DG 
compliance without doing anything. 

Even though WinG 1.0 sliips with WING- 
32.DLL, this DLL uses the Win32sg Univer¬ 
sal Thunk. which Ls not supported under 
Windows NT. This means that your 16-bit 
WinG applications will run under Windows 
NT, but your Win32 ones won't (yet). 

One of the key decisions to make is 
whether to use GDI calls against the 
HBITMAP and DC or roll your own draw¬ 
ing routines. As the WinG documentation 
suggests, assume nothing! When perfor¬ 
mance Ls the only goal, you will almost al¬ 
ways be able to beat GDI by rolling your 
own functions. My experience shows that 
directly manipulating the DIB Lind copy¬ 
ing the results Ls almost always faster than 
using GDI calls. There are. however, cas¬ 
es when it simply isn’t worth the time or 
money to roll your own code. My favorite 
example is TrueType and text. Yes, you 
could piubabiy w rite a slightly faster, more- 
specialized version of the TrueType font¬ 


rendering code, but is it worth it? WinG’s 
primary benefit is that it enables you to 
work around die limitatioas of GDI, all die 
while leveraging existing code and drivers. 

Both Windows 95 and Windows NT 3 5 
include a GDI API call named CreateDIB¬ 
Section, which essentially gives you the 
functionality of WinGCreateDC and WinG- 
CreateBitniap. CreateDIBSection will lie the 
interface to DCI in the future and exLsting 
WinG calls will map direedy to CreateD¬ 
IBSection. Therefore, if you use the WinG 
API calls, you don’t have to worry about 
future compatibility. Also, if you are tar¬ 
geting Windows 95 or Windows NT 3 5 ex¬ 
clusively, I suggest taking a gcxxl look at 
CreateDIBSection. Its use Lsn’t as obvious 
as WinG’s API, but the power Ls there. 

WaveMix 

If you run WinGTest and have a sound 
card, you’ll notice diat WinGTest also pro 
duces sound. Each sound is composed 
completely from WAV files. Most sound 
cards only support a single WAV output. 
To play multiple WAV files simultaneous¬ 
ly, WinGTest uses a new DLL. 

The WaveMix DLL, which first appeared 
in Microsoft Arcade, is available on the 
Microsoft Multimedia JumpStart CD, as 


well as from Microsoft’s Internet FIT site 
and CompuServe forum. It’s also includ¬ 
ed under the unsupported tools section 
of the MSDN CD. WaveMix allows you to 
simultaneously play up to eight PCM- 
sampled sounds. These sounds can be 
Liny uncompressed PCM (pulse code mod¬ 
ulation) wave file or resource. PCM is the 
method used to digitize analog sounds. 
The amplitude of a sound is converted 
into an 8- or 16-bit number and stored 
into a file. The amplitude sampling occurs 
at various intervals: 11,025, 22,050, or 
44,100 times per second. When played 
back, the samples arc converted back into 
an analog waveform, which, depending 
on tlie sampling resolution and rate, will 
be a close facsimile of the original sound. 

WaveMix works by capitalizing on the 
low-level audio services of the Windows 
Multimedia API. It takes a series of PCM 
samples (up to eight) and algebraically 
sums them, creating a single new PCM 
waveform to output to your audio device. 
Some compromise occurs. First, to achieve 
this in real time, it only supports ;m 8-bit 
sample output. This type of sample tends 
to be noisy, but it should be fine for 
games. In addition, on most of today’s 
hardware, supporting over a 22-kHz sam- 


(a) 

ghWinGBackgroundDC = WinGCreateDC(): 

(b) 

hBitmap = WinGCreateBitmap(ghWinGBackgroundDC. 

(BITMAPINF0 far*)&WinGBackgroundDIBHeader. 
(void far*)&ghpWinGBackgroundBitmap); 

(C) 

gbra01dBackgroundBitmap= (HBITMAP) SelectObject (ghWinGBackgroundDC,hBitmap); 

(d) 

StretchDIBits(ghWinGBackgroundDC.0.0,giWindowX.giWindowY.0.0. 

DibWidth(gpdibBackgroundBitmap).DibHeight(gpdibBackgroundBitmap). 
DibPtr(gpdibBackgroundBitmap),DibInfo(gpdibBackgroundBitmap). 

DIB_RGB.COLORS,SRCC0PY): 

(e) 

ghWinGDC = WinGCreateDC(): 

hBitmap = WinGCreateBitmap(ghWinGDC.(BITMAPINF0 far*)&WinGDIBHeader, 

(void far *)&ghpWinGBitmap): 
gbm01dBitmap = (HBITMAP)SelectObject(ghWinGDC,hbitmap); 

<») 

BitBlt(ghWinGDC.0.0.0,giWindowX.giWindowY.ghWinGBackgroundDC.0.0.SRCC0PY): 

(9) 

hDC = BeginPaint(hWnd,&ps): 

SelectPalette(hDC.ghMSJldentityPalette.FALSE); 

RealizePalette(hDC): 

WinGBitBlt(hDC,0.0.giWindowX.giWindowY.ghWinGDC.0.0); 

EndPaint(hWnd,&ps); 


Example JL* (a) Creating a WinG DC; (b) creating a bitmap . (c) selecting the 
new bitmap into the WinG DC; (cl) stretching the bitmap; (e) constructing the 
cioubie buffer; (f) copying the background image into the DC; (g) copying the 
off-screen buffer to the window. 
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pie in real time is probably nor realistic, 
WaveMix allows you to output a 44.1-kHz 
waveform, but you will probably notice 
moments of silence between sounds (the 
process of mixing cannot keep up with 
the playing of the sound). 

For more information about PCM en¬ 
coding, see “The Multimedia Extensions 
for Windows-Enhanced Sound and Video 
for the PC/' by Charles Petzold (MS/, 
March 1991). 

WaveMix does more than just add the 
waveforms together. To support real-time 
mixing, it forms output buffers in a cir¬ 
cular buffer, so while one buffer is play¬ 
ing, the next one can be premixed. This 
premixing introduces some problems 
when you want to insert another sound 
immediately into the output wave. To fa¬ 
cilitate this, WaveMix allows you to flush 
he premixed buffers and remix them w ith 
the new sound in place. 

Finally, WaveMix manages the mixing 
of different-length wave inputs. It will ap¬ 
propriately stop playing on a specific 
channel when there is no more PCM data 
to mix. All of this functionality is hidden 
behind a reasonably simple API. 

Pulling It Together 

To use WaveMix API, you first open a ses¬ 
sion with a call to WaveMixInit or Wave- 
MixConflgU relnit WaveMixInit will con¬ 
figure the session using the parameters in 
the WAVEMEX.INI file. 

The WAVEMIX.INI file is broken up into 
a few sections. In the [General] section, 
the WaieOutDevice setting specifies the 
multimedia output device to utilize start¬ 
ing at 0 (most people will only have one 


WinG provides 
device-independent, 
DOS-Uke , double¬ 
buffering flexibility 


sound output device). If this value is -1, 
WaveMix uses die wave mapper The wave 
mapper is a Control Panel applet that al¬ 
lows a user to define the best wave-output 
devices for particular wave formats. The 
wave mapper adds a layer of processing 
overhead that you’ll most likely find 
unacceptable. 

WaveMixInit obtains die product name 
of the wave-output device by calling the 
Wai&QutGetDeuCaps function from MM- 
SYSTEM, the 16-bit Windows multimedia 
API. It uses this string to look up the ap¬ 
propriate subheading in WAVEMIX,INI for 
a particular product. This is important to 
note, since the stock WAVEMIXJNI in¬ 
cludes settings for only five sound cards. 
If yours isn't one of the five, you have to 
add it; otherwise some rather unimpres¬ 
sive defaults will be used. WAVEMIX uses 
these settings, filling in missing settings 
with defaults from the [Default] section, to 
configure the wave-output device. 
WaieMixConJigimdni! permits you to over¬ 
ride the SamplesPerSec setting with either 


11 1 22, or 44, In addition, WaveMixCon- 
figurelnit permits you to specify whether 
die output will be mono or stereo. This 
cannot be set in WAVEMIX.INl, In my sam¬ 
ple app, I call WaveMLxConfigurelnit to 
set die number of channels to 2 (stereo). 
The rest of the settings are derived from 
die WAVEMIX.INl file; see Example 4(a). 

Once you have a session handle from 
WaveMixInit or WaveMixConfiglirelnii 
open your PCM-eneoded WAV files. Wave- 
MixOpen Wave supports the loading of 
both disk files and embedded resources; 
see Example 4(b). The current version of 
WaveMix only supports PCM-encoded 
WAV files. Since sound cards supporting 
various types of w r ave compression are 
proliferating, I expect WaveMix to support 
these formats in the future. 

Before you can play a loaded WAV, you 
must open a channel in WaveMix. You can 
open diem one at a time, or open a se¬ 
ries of them at once. In Example 4(c), I 
open all of die channels dial I need up 
front, WaveMix then has to be activated 
w ith a call to WaveMixActivate f which al¬ 
locates and releases the sound output de¬ 
vice, since only one application can use 
it at a time. The best place to put this call 
is in die processing of die WM_AdTVATE 
message. That way, iL will always be called 
when the application first starts, and 
WaveMix will allocate and free the output 
device as the application goes from fore¬ 
ground to background; see Example 4(d). 
After all of this, actually playing the sounds 
is a snap. A call to WaveMixPlay, see Ex¬ 
ample 4(e) is all that is required. 

The code in Example 4 can be called 
from any event, which makes hooking up 
sounds to various application events easy. 
It’s important to note that WaveMix uses 
a hidden window with a WM_TIMER mes¬ 
sage to continually mix output buffers. 
Tills means that if your application does 
not relinquish control to Windows peri¬ 
odically and consistently, the output sound 
will start to skip. If you have code in your 
application that does not relinquish con¬ 
trol periodically, then you must call 
WaveMixpump periodically (which I do 
in the processing of WM_CL05E), 

Conclusion 

Between WinG and WaveMix, you have at 
your disposal a rich set of tools to devel¬ 
op Windows-based games. Best of all, diey 
are both free. Aldiough neither API is an 
exhaustive implementation of everything 
dial they can be T diey do show an evolu¬ 
tionary' path toward improving game devel¬ 
opment under Windows. With an eye on 
the future, these APIs give you the flexibi¬ 
lity and performance you need today, with 
compatibility that you'll want tomorrow. 

DDJ 


(a) meConfig.wSize = sizeof(MIXCQNFIG); 

mcConfig.dwFlags = WMIX_CONFIG_CHANNELS; 

mcConfig.^Channels 2: // Start up 

Wavemix 

.ghMixSession = WaveMixConfigurelnitt&mcCoiifig); 

(b) g 1 pMixl=Wa veMixO penW a ve (ghMix S e s a ion. " 1 . wav'" * NULL. WMIX„FILE); 
glpMx2=WaveHix0penWave(ghMixSession."2 *wav",NULL,WMIX_FILE); 
glpMix3"WaveMixQpenWave(ghMixSesaion, "3.wav".NULL,WMIX_FILE): 
glpMix4=WaveMixOp enWave (ghMix S e s a ion." 4. wav 11 . NULL. WMIX_ FILE); 

(c) WaveKix0penChannel(ghMixSess±on»4»WHIX_0FENC0UNT): 

(d) case WM_ACTIVATE: 

// WA,INACTIVE == FALSE; 

WaveMixActivat e(ghMixSes aion, wparam); 
break: 

(e) MixPlay Farame , wSise * aizeof {MIXPLAYPARAMS); 

MixFlayFarams. hMixSe salon = ghMixSeasion: 

MixPlayFarams.hWndNotify = NULL; 

MixP]ayFarams.dwFlage-WMIX_HIPRIORITY; 

MixPlayFarama.wLoops=0: 

MixFlayFarams.iChannel=3; 

MixPlayFarama.lpMixWave=glpMix4; 

WaveMixFlay(^MixFlayFarams): 


Example 4: (a) Configuring the wave output device; (b) opening WAV files; 
(c) opening 4 channels, one per file; (d) activating the device; (e) playing 
sounds by calling WaveMixPlay. 
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RAMBLINGS IN REAL TIME 


BSP Trees 


he answer is: Wendy Tucker. 

The question that goes with that 
answer isn’t particularly interesting 
to anyone but me— but the man¬ 
ner in which I came up with the answer 
might be. 

I spent many of my childhood Hummel's 
at Camp Chingacook, on Lake George in 
New York. Jt was a great place to have 
fun and do some growing up, with swim¬ 
ming and sailing and hiking and lots more. 

When I was 14, Camp Chingacook had 
a mixer with a nearby girl’s camp. As best 
I can recall, I had never had any interest 
in girls before, but after the older kids had 
paired up, 1 noticed a pretty girl looking 
at me, and, with considerable trepidation, 
crossed the room to talk to her. To my 
amazement, we hit it off terrifically. We 
talked nonstop for die rest of die evening, 
and I walked back to my cabin floating 
on air, I had taken a first, tentative step 
into adulthood, and my world would nev¬ 
er be quite the same. 

That was the only time I ever saw her, 
although 1 would occasionally remember 
that warm glow and call up an image of 
her smiling face. That happened less fre¬ 
quently as the years passed and 1 had real 
girlfriends. By the time I got married, that 
particular memory was stashed in some 
back storeroom of my mind. I didn’t think 
of her again for more than a decade. 

A few days ago, for some reason, dial 
mixer popped into my mind as 1 was try¬ 
ing to fall asleep, and I wondered, for die 
first time in 20 years, what that girl’s name 
w T as, The name was there in my mind, 
somewhere; I could feel die shape of it, 
in that same back storeroom, if only I 
could figure out how to retrieve it. 

I poked and worried at that memory, 
trying to get it to come to the surface. I 
concentrated on it as hard as I could and 
even started going through the alphabet 


Michael Ahrash is the author of Zen of 
Graphics Programming and Zen of Code 
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one letter at a time, trying to remember if 
her name started with each letter. After 15 
minutes, 1 was wide awake and totally 
frustrated. I was also farther than ever from 
answering the question; all the focusing 
on the memory was beginning to blur the 
original imprint. 

At this point, I consciously relaxed and 
made myself think about something com¬ 
pletely different. Every time my mind re¬ 
turned to the mystery girl, l gently shift¬ 
ed it to something else. After a while, l 
began to drift off to sleep, and as I did, a 
connection was made, and a name 
popped, unbidden, into my mind. 

Wendy Tucker. 

There are many problems that are 
amenable to the straight-ahead, purely 
conscious son of approach that 1 first tried 
to use to retrieve Wendy’s name. Writing 
code (once it’s designed) is often like that, 
as are some sorts of debugging, and tech¬ 
nical writing, and balancing your check¬ 
book. I find these left-brain activities very 
appealing because they’re finite and con¬ 
trollable; when 1 start one, 1 know r 111 be 
able to deal with whatever comes up and 
make good progress, just by plowing 
along. Inspiration and intuitive leaps are 
sometimes useful, but not required. 

The problem is, though, that neither 
you nor 1 will ever do anything great with¬ 
out inspiration and intuitive leaps, and es¬ 
pecially not without stepping away from 
what’s known and venturing into territo¬ 
ries beyond. The way to do that is not by 
trying harder but, paradoxically, by trying 
less hard, stepping back and giving your 
right brain room to work, then listening 
for and nurturing whatever comes of that. 
On a .small scale, that’s how I remembered 
Wendy's name, and on a laiger scale, that's 
how programmers come up with products 
that are more than me-too, checklist- 
oriented software. 

Which, for a couple of reasons, brings 
us neatly to todays topic, binary space par¬ 
titioning (BSP) trees. First, games are prob¬ 
ably die son of software in which the right- 




brain element is most important—block¬ 
buster games are almost always break¬ 
throughs in one way or another— and 
some very successful games use BSP trees, 
most notably the megahit DOOM. Second, 
BSP trees aren’t intuitively easy to grasp, 
and considerable ingenuity and inventive¬ 
ness is required to get the most from them. 

First, I’d like to thank John Carmack, 
technical wizard of DOOM , for generous¬ 
ly sharing his knowledge of BSP trees, 

BSP Trees 

A BSP tree Is, at heart, nothing more than 
a tree that subdivides space in order to 
isolate features of interest. Each node of 
a BSP tree splits an area or a volume (in 
two dimensions or three dimensions, re¬ 
spectively) into two parts along a line or 
a plane; thus die name J+ binary space par¬ 
titioning,” The subdivision is hierarchi¬ 
cal; the root node splits the world into 
two subspaces, then each of the root’s 
two children splits one of those tw o sub¬ 
spaces into two more parts. This contin¬ 
ues, with each sub space being further 
subdivided, until each component of in¬ 
terest (each line segment or polygon, for 
example) has been assigned its own 
unique subspace. This is, admittedly, a 
pretLy abstract description, buL die work¬ 
ings of BSP trees will become clearer 
shortly; it may help to glance ahead to 
Figures 2 through 6. 

Building a tree that subdivides space 
doesn't sound particularly profound, but 
there’s a lot that can be done with such a 
structure, BSP trees can be used to rep¬ 
resent shapes, and operating on those 
shapes is a simple matter of combining 
trees as needed; this makes BSP trees a 
powerful way to implement constructive 
solid geometry (CSG), BSP trees can also 
be used for hit testing, line-of-sight de¬ 
termination, and collision detection. 

Visibility Determination 

I'm going to discuss only one of the many 
uses of BSP trees: their ability to allow you 
to traverse a set of line segments or poly¬ 
gons in back-to-front or front-to-back or¬ 
der as seen from any arbitrary viewpoint. 
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Figure 1: Visible surface determination via the painter s algorithm: (a) Walls as 
lieived from above; (b) after drawing farthest wall; (c) after drauing next- 
farthest wall; (d) after dra wing nearest wall. 


This sort of traversal can be very helpful 
in determining which parts of each line 
segment or polygon are visible and which 
are occluded from the current viewpoint 
in a 3-D scene. Thus, a BSP tree makes 
possible an efficient implementation of the 
painter’s algorithm, whereby polygons are 
drawn in back-to-front order, with closer 
polygons overwriting more distant ones 
that overlap, as shown in Figures l(b-d). 
(The line segments in Figure 1(a) repre- 
sent vertical walls viewed directly from 
above.) Alternatively, visibility determina¬ 
tion can be performed by front-to-back 
traversal working in conjunction with some 
method for remembering which pixels have 
already been drawn. 'ITie latter approach 
Is more complex, but has die potential ben¬ 
efit of allowing you to early-out from traver¬ 
sal of the scene database when all the pix¬ 
els on the screen have been drawn. 

Back-to-front or front-to-back traversal 
in itself wouldn’t lx j so impressive—there 
are many ways to do that—were it not 
for one additional detail: 'Ihe traversal can 
always be performed in linear time, as 
we’ll see later on. In other words, you can 
traverse, say, a polygon list back-to-front 
from any viewpoint simply by walking 
through the corresponding BSP tree once, 
visiting each node once and only once, 
and performing only one relatively inex¬ 
pensive test at each node. 

It’s hard to get cheaper sorting than lin¬ 
ear, and BSP-based rendering stacks up 
well against alternatives such as z-buffering, 
octrees, z-scan sorting, and polygon sort¬ 
ing. Better yet, a scene database repre¬ 
sented as a BSP tree can be clipped to die 
view' pyramid very' efficiently; huge chunks 
of a BSP tree can lx* lopped off when clip¬ 
ping to the view pyramid, because if a 
splitting line or plane lies entirely outside 
the view volume, then all surfaces on one 
or the other side of the splitting surface 
must likewise be outside the view volume, 
for reasons that will become clear as we 
delve into the workings of BSP trees. 

Limitations of BSP Trees 

Powerful as they are, BSP trees aren’t per¬ 
fect. By far die greatest limitation of BSP 


trees is that they’re time-consuming to 
build, enough so that, for all practical pur¬ 
poses, BSP trees must be precalculated 
and cannot be built dynamically at run 
time. In fact, a BSP-tree compiler that at¬ 
tempts to perfonn some optimization (lim¬ 
iting the number of surfaces that need to 
be split, for example) can easily take min¬ 
utes or even hours to process large world 
databases. 

A fixed world database is fine for walk¬ 
through or flythrough applications, but 
not much use for games or virtual reality, 
where objects constantly move relative 
to one another. Consequently, various 
workarounds have been devebped to al¬ 
low moving objects to appear in BSP tree- 
based scenes. DOOM, for example, uses 
2-D sprites mixed into BSP-based, 3-D 
scenes; note, though, that this approach 
requires maintaining z information so that 
sprites can lx* drawn and excluded prop¬ 
erly. Alternatively, movable objects could 
lx represented as separate BSP trees and 
merged into the BSP tree describing the 
static world anew with each move. Dy¬ 
namic merging may or may not be fast 



Figure 2: A sample set of walls , 
viewed from above. 


enough, depending on the scene, but 
metging BSP trees tends to be quicker than 
building them, because the BSP trees be¬ 
ing merged are already spatially sorted. 

Another possibility would lx to gener¬ 
ate a per-pixel z-buffer for each frame as 
it’s rendered, to allow dynamically chang¬ 
ing objects to be drawn into the BSP- 
based world. In this scheme, the BSP tree 
would allow fast traversal and clipping of 
the complex, static world, and the z-buffer 
would handle the relatively kxalized vis¬ 
ibility determination involving moving ob¬ 
jects. The drawback of this is the need 
for a memory-hungry z-buffer; a typical 
640x480 z-buffer requires a fairly appalling 
600K, with equally appalling cache-miss 
implications for performance. 

Yet another possibility would be to build 
the world so that each dynamic object falls 
entirely within a single subspace of the 
static BSP tree, rather than straddling split¬ 
ting lines or planes. In this case, dynam¬ 
ic objects can lx treated as points, which 
are then just sorted into the BSP tree on 
the fly as they move. 

The only other drawbacks of BSP trees 
that I know of are the memory required 
to store the tree, which amounts to a few 
pointers per node, and the relative com- 




Figure 4: Split of wall C’s front subspace along the line of wall D. 
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plexity of debugging BSP-tree compila¬ 
tion and usage; debugging a large data set 
being processed by recursive code (which 
BSP code tends to be) can be quite a chal¬ 
lenge. Visual tools which, like the BSP 
compiler that I’ll present next time, de¬ 
pict the process of spatial subdivision as 
a BSP tree is constructed can help a great 
deal with BSP debugging. 

Building a BSP Tree 

Now that we know a good bit about what 
a BSP tree is, how it helps in visible sur¬ 
face determination, and what its strengths 
and weaknesses are, let’s take a look at 
how a BSP tree actually works to provide 
front-to-back or back-to-front ordering. 
This month’s discussion will be at a con¬ 
ceptual level, with plenty of figures; next 
time we’ll get into mechanisms and im¬ 
plementation details. 

I’m going to discuss only 2-D BSP trees 
from here on out, because they’re much 
easier to draw r and to grasp than their 3-D 
counterparts. Don’t worry, though; the 
principles of 2-D BSP trees using line seg¬ 
ments generalize directly to 3-D BSP trees 
using polygons. Also, 2-D BSP trees are 
quite powerful in their own right, as evi¬ 
denced by DOOM , which is built around 
2-D BSP trees. 

First, let’s construct a simple BSP tree. 
Figure 2 shows a set of four lines that 
will constitute our sample world. I’ll re¬ 
fer to these as walls viewed from direct¬ 
ly above, because that’s an easily visual¬ 
ized context in which 2-D BSP trees 
would be useful in a game. Note that 
each wall has a front side, denoted by a 
normal (perpendicular) vector, and a back 
side. To make a BSP tree for this sample 
set, we need to split the world in two, 


then each part into two again, and so on, 
until each wall resides in its own unique 
subspace. An obvious question, then, is 
how we should carve up the world of 
Figure 2. 

There are many valid ways to carve up 
Figure 2, but the simplest is just to carve 
along the lines of the walls themselves, 
with each node containing one wall. This 
is not necessarily optimal in the sense of 
producing the smallest tree, but it has the 
virtue of generating the splitting lines with¬ 
out expensive analysis. It also saves on 
data storage, because the data for the walls 
can do double duty in describing the split¬ 
ting lines as well. (Putting one wall on 
each splitting line doesn’t actually create 
a unique subspace for each wall, but it 
does create a unique subspace boundary 
for each wall; as we’ll see, this spatial or¬ 
ganization provides for the same unam¬ 
biguous visibility ordering as unique sub¬ 
spaces w'ould.) 

Creating a BSP tree is a recursive pro¬ 
cess, so we'll perform the first split and 
go from there. Figure 3 shows the world 
carved along the line of wall C, into two 
parts: walls that are in front of wall C, and 
walls that are behind. (Any of the walls 
would have teen an equally valid choice 
for the initial split; we’ll return to the is¬ 
sue of choosing splitting walls next time.) 
Ibis splitting into front and back Is the es¬ 
sential dualism of BSP trees. Next, in Fig¬ 
ure 4, the front subspace of wall C is split 
by wall D. This is the only wall in that 
subspace, so we’re done with wall C’s 
front subspace. 

Figure 5 shows the back subspace of 
wall C being split by wall B. There’s a dif¬ 
ference here, though: Wall A straddles the 
splitting line generated from wall B. Does 



Figure 5: Split of wall C’s back subspace along the line of wall B. 



wall A belong in the front or back sub¬ 
space of wall B? 

Both, actually. Wall A gets split into two 
pieces, which I’ll call wall A and wall E; 
each piece is assigned to the appropriate 
subspace and treated as a separate wall. 
As shown in Figure 6, each of the split 
pieces then has a subspace to itself, and 
each becomes a leaf of the tree. The BSP 
tree is now complete. 

Visibility Ordering 

Now that we’ve successfully built a BSP 
tree, you might justifiably be a little puz¬ 
zled as to how any of this helps with vis¬ 
ibility ordering. The answer is that each 
BSP node can definitively determine which 
of its child trees is nearer and which is far¬ 
ther from any and all viewpoints; applied 
throughout the tree, this principle makes 
it possible to establish visibility ordering 
for all the line segments or planes in a BSP 
tree, no matter what the viewing angle. 

Consider the world of Figure 2 viewed 
from an arbitrary angle, as in Figure 7. 
The viewpoint is in front of wall C; this 
tells us that all walls belonging to the front 
tree that descends from wall C are near¬ 
er along every ray from the viewpoint than 
wall C is (that is, they can’t be occluded 
by wall C). All the walls in wall C’s back 
tree are likewise farther away than wall C 
along any ray. Thus, for this viewpoint, 
we know for sure that if we’re using the 
painter’s algorithm, we want to draw all 
the walls in the back tree first, then wall 
C, and then the walls in the front tree. If 
the view'point had been on the back side 
of wall C, this order would have been 
reversed. 

Of course, we need more ordering in¬ 
formation than wall C alone can give us, 
but we get that by traversing the tree re¬ 
cursively, making the same far/near deci¬ 
sion at each node. Figure 8 shows the 
painter’s algorithm (back-to-front) traver¬ 
sal order of the tree for the viewpoint 
of Figure 7. At each node, w r e decide 
whether we’re seeing the front or back 
side of that node’s wall, then visit which¬ 
ever of the wall’s children is on the far 
side from the viewpoint, draw the wall, 
and visit the node’s nearer child, in that 



Figure 7: Viewing the BSP tree from 
an arbitrary angle. 
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order. Visiting a child is recursive, involv¬ 
ing the same far-near visiting order. 

The key is that each BSP splitting line 
separates all the walls in the current sub¬ 
space into two groups relative to the view¬ 
point, and every single member of the far¬ 
ther group is guaranteed not to occlude 
every single member of the nearer. By ap¬ 
plying this ordering recursively, the BSP 
tree can be traversed to provide back-to- 
front or front-to-back ordering, with each 
node being visited only once. 

The type of tree walk used to produce 
front-to-back or back-to-front BSP traver¬ 
sal is known as “inorder.” (See my article, 
“Good Causes, Good Code," PC Tech- 



Figure 8: Back-to-front traversal of 
the BSP tree as viewed in Figure 7: 
Based on J'ar/near tests at each node. 
“F” and “N” indicate the respective far 
and near children of each node. 


niques, October 1994, or any book on data 
structures for a discussion of inorder walk¬ 
ing.) The only special aspect of BSP walks 
is that a decision lias to be made at each 
node about which way the node’s wall is 
facing relative to the viewpoint, so we 
know which child tree is nearer and which 
is farther. 

Example 1 shows a function that draw's 
a BSP tree back-to-front. The decision 
whether a node’s wall is facing forward, 
made by WallFacingForward( ) in Listing 


void WalkBSPTree(NODE *pNode) 

C 

if (WallFacingForward(pNode) { 
if (pNode->BackChild) ( 

WalkBSPTree(pNode->BackChild); 

) 

Draw(pNode): 

if (pNode->FrontChild) ( 

WalkBSPTree(pNode->FrontChild); 

) 

} else ( 

if (pNode->FrontChild) ( 

WalkBSPTree(pNode->FrontChild): 

) 

Draw(pNode); 
if (pNode->BackChild) C 

WalkBSPTree(pNode->BackChild); 

) 

) 

) 


Example 1: Function that draws a 
BSP tree hack-to-front. 
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One, can, in general, lie made by generat¬ 
ing a normal to the node’s wall in 
screenspace (perspective-corrected space 
as seen from the viewpoint) and checking 
whether die z component of the normal is 
positive or negative, or by checking die sign 
of the dot product of a viewspace (non- 
perspective-corrected space as seen from 
the viewpoint) normal and a ray from the 
viewpoint to the wall. In 2-D, the deci¬ 
sion can be made by enforcing the con¬ 
vention that when a wall is viewed from 
the front, the start vertex is leftmost; then 
a simple screenspace comparison of die 
x-coordinates of die left and right vertices 
indicates which way the wall is facing. 

Finally, be aware diat BSP trees can of¬ 
ten be made smaller and more efficient by 
detecting collinear surfaces (like aligned 
wall segments) and generating only one 
BSP node for each collinear set, widi the 
collinear surfaces stored in, say, a linked 
list attached to that node. Collinear surfaces 
parddon space idendcally and can’t occlude 
one another, so it suffices to generate one 
splitting node for each collinear set. 

BSP Trees, Continued 

Next time, I’ll build a BSP-tree compiler, 
then put together a rendering system built 
around the BSP trees die compiler gener¬ 
ates. in die meantime, there’s a World Wide 
Web page on BSP trees under construction 
at http://w'ww.graphics.cornelLedu/bsp- 
faq; as I write this, the page contains little 
more than an outline of things to come, 
but if the contents live up to the promise 
of the outline, it could lx? worth checking 
out by the time you read this. 

Recommended Reoding 

Short on space though I am, I’d be remiss 
if I didn’t point out one of the most valu¬ 
able articles you’re likely to come across 
this year. Chris Hecker’s column in the 
April 1995 issue of Game Developer mag¬ 
azine is by far the best discussion of per¬ 
spective texture mapping I’ve seen. Check 
it out; you won’t be sorry. 
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San Jose’s 
High-Tech 

he city of San Jose is going to dig 
a long ditch that will pass near 
my house, according to the map 
published in the local newspaper. 
The minimum feature design rules for 
Lhis ditch will be about 2xl0 6 microns 
(this technical detail should allow me 
to sneak a ditch past DDJ editors), 
Nothing unusual? Well, 1 live in Santa 
Clara, and it is the city of San Jose dig¬ 
ging the ditch. 

You .see, us folks in California are short 
of water. Rice farmers in California aren’t 
short of water—they get 85 percent of 
the state’s ample supply. It takes three gal¬ 
lons of water to grow each grain of rice. 
The California legislature has more friends 
of rice farmers than friends of people, so 
there’s not much water left over for peo¬ 
ple. That’s why San Jose is going to dig 
the ditch. 

The ditch is going to carry reclaimed 
waste water (from sewage plants) to be 
used exclusively for watering law r ns, 
mostly industrial-park lawns. Given that 
rice Is more important than people, this 
is a good idea. 

But San Jose officials have a better idea: 
As long as they’re digging a long ditch that 
meanders all over the place, even into the 
city of Santa Clara, why not run fiber-optic 
cable in that ditch? Yes, San Jose is going 
into the cable/networking business as an 
entrepreneur, 

San Jose is cleverly going to tax any¬ 
body other than die city of San Jose who 
competes in San Jose using fiber cable, A 
fabulous idea: Tax your competitors! (Wait 
until Borland and Novell hear about this.) 
The grounds are that fiber cable is a util¬ 
ity, and utilities can be taxed by dties, This 
absolutely assures that my section of the 


Hal is a hardware engineer who some¬ 
times programs. He is the former editor of 
DTACK Grounded and can be contacted 
through the DDJ offices , 



Hal W. Hardenbergh 


ditch, located in Santa Clara, will be taxed 
by the city of Santa Clara. (There is no 
municipal idea so powerful as a new tax.) 

A1 Gore tells me that the Information 
Highway is coining. With video capabili¬ 
ty added, the Highway needs fiber-optic 
cable. It'll arrive complete with a lot of 
federal censors and regulators. Schools 
and libraries will be connected for free, 
but die feds won't foot the bill. Who’ll pay 
lor this largess and for all the accompa¬ 
nying bureaucracy? Looked in the mirror 
lately? 

i turn on Charlie Rose on PBS and I 
hear some talking heads tell me that a 
consortium of Baby Bells are trying to re- 
cruit Howard Stringer, head of the CBS 
TV network, to form a new, interactive- 
video cable enterprise. This is typical of 
a dozen credible (meaning they can rea¬ 
sonably expect to raise a few billion dol¬ 
lars) proposals; there are several dozen 
less credible. 

The well-known futurist George Gilder 
wrote “Telecosm: The Bandwidth Tidal 
Wave" in die December 1994 Forbes ASAP, 
It looks in part very much like a public- 
relations release for Tiger," a video-on- 
demand system backed by Bill Gates, of 
whom you may have heard. 

I’m afraid that some day soon I’ll hear 
pounding on my front door; when I 
open it, I’ll find 17 people with 17 dif¬ 
ferent cables competing for my attention. 
The problem with this prospect is that 
theyll be thrusting 17 different invoices 
at me. 

Sipping from a Firehose 

The thesis of Gilder’s article is that net¬ 
work bandwidth is increasing much faster 
than the internal bandwidth in our PCs, 
An accompanying graphic shows the 
crossover in 1996, after which network 


bandwidth makes the PC look like dog- 
meat: “...(network) bandwidth will expand 
5 to 100 times as fast as the rise of micro¬ 
processor speeds,.,a firehose of gigabits 
(billions of bits)," 

Gates’s Tiger is an all-software, PC-based 
approach to handling video-on-demand 
and all that bandwidth. But maybe an all- 
software approach won’t work. 

Consequently, Gilder introduces us to 
MicroUnity, w a flagrantly ambitious (Sili¬ 
con Valley) startup." MicroUnity is fund¬ 
ed by, you guessed it, Microsoft. Micro- 
Unity plans to build not a microprocessor 
but a mediaprocessor, one drat can han¬ 
dle “not less than 400 billion bits per sec¬ 
ond" while replacing special-purpose 
(video?) multimedia devices. This media- 
processor will have to be “hundreds of 
times faster than a Pentium." Flagrantly 
ambitious indeed! 

Naturally (?}, die video stream going out 
over those fiber cables will be compressed 
using MPEG standards. For this to happen 
in real time, you need a supercomputer 
that can execute video operations 1000 
times faster than the raw video bits (ac¬ 
cording to Gilder, but this sounds right). 


I f network bandwidth is really in¬ 
creasing up to 100 times Faster than 
microprocessor performance, why 
not wait two to six weeks for net¬ 
work bandwidth to increase so that 
video compression need not be used? 
That eliminates both the high-per¬ 
formance video-compression pro¬ 
cessor required for real-time MPEG 
and the need to decompress at the 
receiving end. 

Look: Video compression is an ex¬ 
pensive technique used to conserve 
a scarce resource— bandwidth. If 
bandwidth is really increasing so 
swiftly, it ain’t scarce. Who else sees 
a credibility problem here? 
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At the receiving end, code division mul¬ 
tiple access (CDMA) needs nearly as much 
video processing power. 

At this point, when I’m about to be 
buried m gee-whiz, Gilder admits that In¬ 
tel’s Andy Grove “does not believe this 
possible,” Whew! 

Interactive Couch Potatoes? 

I've often wondered just what those 17 
fiber-optic cable purveyors will offer me 
when they converge on my front porch. 
One answ r er is, apparently, interactive 
TV, This has been tried on a small scale. 
I've yei to read of the vast success of 
interactive TV. The only time I physi¬ 
cally respond to TV (as in to cheer) is 
on the (currently rare) occasions when 
USC stomps some football opponent, as 
it did in one of the minor bowl games 
last season. Hey, when I attended lJSC’s 
University College (night school), USC 
was a football powerhouse. 

Okay, interactive TV won’t work for 
the mass populace. Neither will its sib¬ 
ling, home shopping. You need lots of 
money to do much home shopping and 
lots of money is w hat the mass populace 
don't got. 

Instantly available CNN-woridwide TV 
news (our invasion of Panama was on 
CNN five minutes after the invasion start¬ 
ed) is already here on the non-fiber-optic- 
cable we've had all along. 

I hate to tell you tins, but the smart 
money is on video-on-demand, which 
translates into movies-on-demand, which 
means you can tap into your choice of 
available movies. Your choice will start 
at your convenience, to a resolution of 
15 minutes. “Available movies" means 


N ine-gigabyte drives go for $4500 
these days, so it costs SI500 
to store an MP LG-compressed 
movie. If magnetic-disk-storage cost 
per megabyte continues to drop by a 
factor of 2 each year, storage costs 
will drop to 5200 per movie in three 
years. 

The problem is. in three years we’ll 
be able to buy a CD-like, digital laser 
disk that'll store a full-length movie for 
$15, I assume you'll be able to rent one 
of these disks for $2 to $3 r thus re¬ 
placing low-quality, short-lived video 
tape with high-quality, long-lived dig¬ 
ital laser disks. Tills w ill be powerful 
economic competition for video- on- 
clemand. 

Do you want to buy stock in a com¬ 
pany that’s going to invest hundreds 
of millions, perhaps billions, of non- 
recoverable dollars in the infra stric¬ 
ture needed to deliver movies via fiber 
optics rather than by digital laser disk? 


Intel is just now 
bringing online a 
0.5 to 0.4 micron 
production facility 


the ones currently stored on the network 
supplier's hard-disk drives. The Jazz 
Singer and Citizen Kane won't be in¬ 
cluded, Given politics, Debbie Does Dal¬ 
las won't tie available either, even though 
such movies are very popular as video 
rentals. 

Check, Please 

How much will all this cost? The best es¬ 
timate For video-on-demand over fiber¬ 
optic cable that IVe seen so far is that it'll 
cost subscribers four times as much as ex¬ 
isting TV cable, about $120 a month. That's 
a lot of money for federally regulated car 
chases on demand! 

According to Gilder, three MPEG- 
compressed movies can be stored on a 
9-gigabyte Seagate Banacuda disk drive. 
Given a “farm" of several hundred disk 
drives at Network Central, that’s lots of 
movies “on demand" Will the movie you 
want to see tonight be currently stored on 
hard disk-* (We don’t need real-time video 
compression to load movies onto those 
disk drives, so we can lose the super¬ 
computer.) 

What is Success? What's Failure? 

IBM originally planned to sell a very few 
hundred thousand PCs. Meeting this ob¬ 
jective would have lieen judged a success. 
But IBM is selling millions of PCs every 
year, and tliis is widely considered a fail¬ 
ure. Let s keep this in mind. 

Gilder's Telecom seems based on three 
tenets: 

• N transistors on a given silicon die 
results In N 2 performance and val¬ 
ue— a tad overstated, but not egre¬ 
gious! y so. 

• N linked computers results in per¬ 
formance and value (Gilder “credits” 
Ethernet inventor Bob Metcalfe with 
this one). I think this is whacko; almost 
every supercomputer maker using mas¬ 
sively parallel processors—and there 
have been a lot of them—has already 
gone bankrupt. The optimistic view is 
that N linked computers result in al- 
most-N performance. 


Gilder may be adapting Metcalfe's 
view r of die huge, loosely coupled Inter¬ 
net and wrongly applying it to a tightly 
coupled set- top media processor. 

* With bandwidth far exceeding the ca¬ 
pacity of die desktop computer's CPU, 
the CPU will simply be bypassed, Right. 
We call tiiis TV.” (This tenet consigns 
Tiger, Gates's a 11-software approach, to 
the outer darkness.) 

The fact that one of Gilder's tenets is 
obviously w r rong doesn't mean that the 
yet-undefined fiber-optic-network indus¬ 
try will fail. On the other hand, many mil¬ 
lions of network subscribers won't guar¬ 
antee the industry's success. 

Building Microllnity's 
Medioprocessor 

MicroUntty, funded by Microsoft, promised 
in 1994 to deliver 10,000 set-top media- 
processors in 1995. Don’t laugh t it could 
happen. (Seriously, everyone involved re¬ 
gards this as a high-risk gamble.) Here's 
how they are proceeding: 

The mediaprocessor (MP) will have a 
very wide data bus. Pentium’s 64-bit bus 
will look narrow in comparison. 

The MP will be built using design rules 
about five times smaller than the Pentium; 
almost a tenth of a micron. This allows 25 
times as many transisters for a given die 
size, as compared to the Pentium. 

The MP will take an existing industry' 
trend—CPU operating voltages have 
dropped from 5 volts to as low as 3d 
volts—to its logical conclusion and use a 
0.5-volt power supply, 

The MP will use an idea (already proved 
in low er-integration devices) that I think is 
brilliant: a signal layer using air, not silicon 
oxide, lor insulation. The dielectric constant 
is far lower, and the impedance is propor¬ 
tionally higher, Even the signal-propagation 
speed is faster (trust me on tliis stuff; this 
is my pidgin). Regrettably, dense CPUs 
need many signal layers, and tliis approach, 
using air-insulated gold wires, will only 
work at the topmost signal layer. 

All tiie aforementioned ideas are fun¬ 
damentally good; the devil is in the de¬ 
tails, If it were practical to make CPUs us¬ 
ing 0.1-micron design rules, 0,5-voir 
power, and hugely wide data buses, then 
somebody would be doing it right now, 
Intel, the leading microprocessor pro¬ 
ducer, is just now' bringing online a 
0,5-0.4 micron production facility' at its 
new fab in Rio Rancho, just outside Al¬ 
buquerque, Production at or near 0.1 mi¬ 
cron? In 1995, that's “Fantasy Island - ' stuff 
“Da plane, da plane!” 

For you hardware types, there’s the 
ground bounce and nonexistent noise 
margins associated w ith vastly wide data 
buses and a half-volt power supply (the 
signal sw T ing is, at most, ±0.25 volts). 
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Now for the good news- A technolo¬ 
gy tour-de-force similar to the media- 
processor was successfully pulled off 
once. The year was 1982 and the com¬ 
pany was Hewlett-Packard, HP invested 
die then unheard-of sum of $90 million 
in the design of a 32-bit CPU using de¬ 


sign rules that were then as radical as 
those of the mediaprocessor today; see 
Figure 1, 

This processor was highly successful, 
it had an unexpectedly high production 
yield, or proportion of good chips per 
wafer, HP restricted its use to HP’s pro¬ 


prietary minicomputers and so suc¬ 
ceeded, In terms of IBM's original ob¬ 
jective for the PC, Had HP offered the 
processor for general sale, it might have 
ultimately sold millions and thus have 
been regarded as a failure: Why spend 
S90 million to make your competitors’ 
computers run faster? 

Economic Cooperation and 
Competition 

How will various network services (the 
Info Highway, home shopping, interac¬ 
tive TV, video-on-demand) share the nec¬ 
essary infrastructure and income stream? 
If video-on-demand is killed off by rent¬ 
ed digital laser disks, are the remaining 
services worth $ 120/month to the mass 
populace? I hate to mention this in a fam¬ 
ily magazine, but the Politically Incorrect 
fact that pornography is readily available 
at the rental store but not over federally 
regulated networks is a powerful eco¬ 
nomic force against video-on-demand, 

I think tills whole thing w r ill turn out 
just like HDTV: Politics and economics 
will swamp the technology. And you have 
doubtless noticed that after a decade of 
hoopla, you still don't have HDTV. 
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World wide, Multi-Edit lias become the DOS programmer's editor of choice. 
Now it's available for Windows! Imagine, the power and flexibility that 
Multi-Edit is known for, combined with the integration and graphical ease 
of Windows. You will sacrifice nothing making the move to a Windows 
editor. Multi-Edit for Windows is FAST and extremely POWERFUL. 

'y total integration - Turn Mu.Iti-Edit for Windows 
1 into vouniwn personalized IDE. Integra teal! your 
V tools together. Compile, link ,rnd make without 
H leaving the editor. Integrate into your existing 
l environment through powerful DDE and DLL 
support* l ink in your compiler's tor any other) 
help files for full can text/language-sensilivehelp. 
Unparalleled integration with most VCS systems, 
indudingPVCS,TLl ELSourceSafeand MKS-RC5, 


Complete Customization - Redefine the keyboard, 
customize the menus, modify the toolbars or create 
new ones, change every setting imaginable! All 
without touching any macros Or .ini files. 

Small Footprint - Some Windows editors require 
several meg of RAM just to run. Multi-Edit for 
Windows requires only 500k, It can edit a 200 meg 
file, even if yon only have 4 meg of RAMI 


tit tTwlMrwrta of their respective 
pert tit Wife proitnrL American 
'it tamil Mime if Ptiek 1 ivitmefL'c, 


* Edit up to DOS, UNIX nr binjrv 

tiles of almost unlimited &ize. \ 

* Synchronized,, interactive File A 

Compare: 

* Construct male}]ing Jrtd trinpljlu-i J 

* Source code taking and browsing r 

■ ! 11 ti’^ra t«il Spctfchtrirker ^ 

■ Session moii.iger lets you fuggk 
multiple p to tecta! 

* Fop-up ASCII charti lext niter amt 
notebook. 

* Multiple file Search ami Rrflaml 

■ l ull regularevpryssion support* 

* Hen Edttingl 

* Svrtl.ni liiefilightirg . 
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* t’.run I aim ns tur BRIEF, 

Word Star jnd others- YHH 

■ CfiluTTin blnik^! 

* Drag kind drop editing: 

Much move! 

Muiti-Edit for Windows S 199 
Specitri pricing for registered 
Multi-Edit DOS users. 

1-800-899-0100 


Powerful Extensibility - The enhanced 
macro Language is now so powerful, 
you can write entire Windows apps in 
it. With structures, arrays, DLL import, 
and a familiar Olike syntax, you can do 
almost anything, fn addition, Multi- 
Edit for Windows provides a till I DLL 
API, You can extend Multi-Edit in your 
favorite language, or integrate its edit¬ 
ing power into your iipps! 

Workgroup Support - Complete 
network support, including file locking, 
muIti-iiser co n figu ration, and MAPl/MS 
.Mail integration. 


CIRCLE MO. 7 ON READER SERVICE CARD 





















































PATTERNS AND SOFTWARE DESIGN 


Designing Objects 
for Extension 



T he key to creating reusable software 
lies in knowing people’s needs and 
anticipating how those people might 
reuse your software to meet those 
needs. To accomplish this, you must con* 
sider how your system might change over 
its lifetime and be aware of typical caus¬ 
es of redesign. Among the many causes 
for changes are the evolving requirements 
of current users and the needs of new 
users. Other causes might be intrinsic to 
the business environment in which your 
softw are Is used, or stem from changes in 
technology or platforms. 

If places where such modifications oc¬ 
cur are not isolated or decoupled from 
the rest of the system, the resulting 
changes will cause modifications through¬ 
out the software and risk the introduction 
of reuse errors. The design issue then is 
to find and separate the potentially chang¬ 
ing parts of an application from its more 
stable parts. This idea is not new, and 
analogies can be found in other do¬ 
mains— building and ardiitecture, for in¬ 
stance. 

In his wonderful and thoughtful book 
How Buildings Learn (Viking, 1994), Stew¬ 
art Brand considers buildings as consist¬ 
ing of six layers: site (its physical space 
on ground), structure (exterior and load- 
bearing w r alls), skin (exterior brickwork, 
cladding), services (electrical, plumbing), 
space plan (interior w'alls, windows, ceil¬ 
ings), and stuff (furniture). Brand notes 
that these layers evolve at different rates 
during die life of a building. Sites of build¬ 
ings often exist for hundreds of years, 
whereas the furniture tends to move fre¬ 
quently. Brand also notes tiiat these lay¬ 
ers shear against each other as they 
change at different rates. The slow-moving 


Richard and Erich are coauthors of 
Design Patterns: Elements of Reusable 
Object-Oriented Software (Addison-Wesley. 
1994). They 1 can be reached at Richard 
.Heltyi@dmr.ca and Erich_Gamma@ 
Taligent.com , respectively. 


Richard Helm and 
Erich Gamma 


site and structure systems dominate the 
fast-moving space-plan and stuff systems. 
He observes that “an adaptive building 
has to allow slippage between die differ- 
endy paced systems. If not, the slow sys¬ 
tems blcxrk the fast ones, and the fast ones 
tear up the slow.’* If you lay your electri¬ 
cal and plumbing services w ithin the con¬ 
crete slab of your house, you’ll have trou¬ 
ble adding new w iring or fixing blocked 
drains. 

The same ideas apply to software. There 
Is typically a relatively stable, core appli¬ 
cation architecture (event driven, client/ 
server, blackboard, or whatever), around 
which exist less stable layers, from slow- 
moving subsystem structures, to fast- 
moving details of the user interface. Just 
as in buildings, the key to developing an 
extensible software system Is for these lay¬ 
ers to be able to slip and shear against 
each other. When they cannot, you often 
have a reuse error. There are multiple 
causes of reuse errors: 

Algorithmic dependencies. Algorithms 
are often extended, optimized, and re¬ 
placed during development and reuse. Ob¬ 
jects that depend on an algorithm (both 
its behavior and data structures) w ill have 
to change when the algorithm changes. 
Therefore, algorithms likely to change 
should be Isolated from the rest of the ap¬ 
plication. 

Tight coupling. Classes that are tight¬ 
ly coupled are hard to reuse in isolation, 
since they depend on each other. Tight 
coupling leads to monolithic systems, 
where you can’t change or remove a class 
without understanding and changing many 
other classes. The system becomes a 
dense, brittle mass that’s hard to learn, 
port, and maintain. Techniques such its 
abstract coupling and layering help cre¬ 


ate loosely coupled systems. Abstract cou¬ 
pling means that an object talks to another 
object by using an interface defined by 
an abstract class. This enables the object 
to communicate with objects of different 
concrete subclasses. 

Creating an object by specifying a 
class explicitly. Specifying a class name 
when you create an object commits you 
to a particular implementation instead of 
a particular interface. This commitment 
can complicate future changes if the im¬ 
plementations change. One way to avoid 
such commitment is to make requests to 
instantiate classes through a third-party 
factory object. 

Dependence on specific operations. 

When you specify a particular operation 
in a request, you commit to a particular 
way of satisfying that request. By avoid¬ 
ing hard-coded requests for operations, 
you make it easier to change the way a 
request gets satisfied. 

Design patterns can help you avoid 
many reuse errors by ensuring that a sys¬ 
tem can change in specific w r ays. Each de¬ 
sign pattern lets you vary some aspect of 
system structure independently of other 
aspects, thereby making a system more 
robust to a particular kind of change. 
There are patterns which concern the ex¬ 
tensibility of objects, the flexible creation 
of objects, the distribution of responsibil¬ 
ities, and patterns in managing relation¬ 
ships between objects. We will look at 
some of these patterns in later columns. 
This month we will look at patterns for 
designing extensible objects. 

Creating Extensible Objects 

Since an object is defined by its class, ex¬ 
tensions to the object are usually defined 
through class inheritance—by creating 
subclasses of the original class. Inheritance 
is a compile-time mechanism for extend¬ 
ing a class and reusing implementations. 
While simple and supported in most 
object-oriented languages, class inheri¬ 
tance does have some problems: 
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* It exposes subclasses 10 their parent 
class's implementation, which intro¬ 
duces dependencies and breaks en¬ 
capsulation of the parent with respect 
to the child. Parent classes appear as 
White Boxes . 

* It implies a commitment to a particular 
implementation rather than an interface 
(unless the class is derived from an ab¬ 
stract class with no representation). 

* Extensions defined through inheritance 
are defined at compile time and can't 
be redefined or changed at run time. 

* Inheritance doesn't extend a particular 
object; rather it specifies a new imple¬ 
mentation of the object based on the 
implementation of an old. To actually 
use the extension, you must be able to 
instantiate the extended class where you 
instantiated the old. 

As we discussed in our previous col¬ 
umn, object composition offers an alter¬ 
native to inheritance. Instead of compos¬ 
ing classes to create new functionality, 
object composition creates new function¬ 
ality by combining objects in new ways. 

I lowever, object composition Is a little 
more difficult to use than inheritance. It 
requires careful attention to interfaces de¬ 
fined by objects. It also increases die dif¬ 
ficulty in understanding a system: Rela¬ 
tionships between objects are more 
implicit, mast of the code only uses ob¬ 
jects through interfaces, and the imple¬ 
mentation classes of the objects behind 
these interfaces are unknown. Despite 
these difficulties, object composition can 
offer a more flexible alternative to inher¬ 
itance as a reuse mechanism. 

So how do you use object composition 
to create extensible objects? First, you need 
to consider what it is you are extending: 
an object's behavior for particular states, 
the algorithms it uses, properties and in¬ 
dividual operations, or its interface. There 
are four patterns that address these ex¬ 
tensions, three of which—Decorator, Strat¬ 
egy, and State— are discussed in our book 
Design Patterns: Elements of Reusable 
Object-Oriented Software. The fourth is a 
new pattern called “Extension Objects,” 
which we introduce in this column. To 
simplify the discussion and permit com¬ 
parison, we will name the class to lie ex¬ 
tended ExlendedObject 

Extending Algorithms 

Objects employ algorithms to implement 
their operations. The Strategy pattern, 
which we discussed in our previous col¬ 
umn, allows an object to be extended with 
new kinds of algorithms. The basic Idea 
behind the Strategy pattern is dial each al¬ 
gorithm is encapsulated and accessed 
through a common interface to create a 
family of strategies. At run time, the Ex- 


Object composition 
can offer a more 
flexible alternative to 
inheritance as a 
reuse mechanism 


tendedObjea instance is configured with 
a particular Strategy class. 

Extending State-Specific Behavior 

All objects have internal state. Sometimes 
die behavior of an object depends on this 
state. At issue is how to represent this 
state-specific behavior, isolate each state's 
behavior, and permit new states and be¬ 
haviors to be added. The State pattern 
does this as follows: Ii encapsulates all 
state-specific behavior as a state object 
and creates state objects for each distinct 
state. The ExtendedOhject forwards state- 


specific behavior to the state object. To 
change the ExiendedOhjeefs behavior, 
configure it with a different state object. 

Extending Properties and 
Operations 

How can you extend properties and op¬ 
erations? How can you add state and al¬ 
ter the behavior of operations? The Dec¬ 
orator pattern does this by “wrapping” up 
the Extended Object in a decorator object. 
The decorator presents die same interface 
to clients as the decorated object (clients 
will therefore not notice the presence of 
the decorator object). Most requests made 
of the decorator are forwarded directly to 
the decorated object. However, for some 
requests the decorator adds, removes, or 
modifies the behavior of the decorated 
object. 

Extending Interface 

All objects present interfaces to clients to 
allow manipulation. However, it is diffi¬ 
cult to anticipate how clients wall want to 
use an object, and so it is hard to create 
a general-purpose interface for all possi¬ 
ble clients. Attempts to do so will result 
in large, clumsy, bloated interfaces which 
tend to detract from the abstraction the 
object represents. 
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PATTERNS AND SOFTWARE DESIGN 


The Extension Objects pattern describes 
a solution to this problem of extending 
interfaces. There are many different ways 
to write patterns. This one is based on the 
format we introduced in our book. 

Extension Objects 

Category: Object Structural 

Intent Enable clients to extend the in¬ 
terface of an object. Additional interfaces 
are defined by extension objects. 

Motivation. Consider a compound- 
document architecture as currently pro¬ 
moted by OLE 2, OpenDoc, and soon Tal- 
igent’s CommonPoint. A compound doc¬ 
ument is made of components that are 
managed and arranged by container com¬ 


ponents. The infrastructure for a com¬ 
pound document requires a common in¬ 
terface to various components such as 
text, graphics, or spreadsheets. Let’s as¬ 
sume that this interface is defined by an 
abstract class Component. How can we 
define additional interfaces for compo¬ 
nents that allow clients to use component- 
specific functionality? 

You cannot define all possible opera¬ 
tions on components as part of the gen¬ 
eral Component abstraction. First, it is 
not possible to foresee all operations that 
component writers would like to per¬ 
form. Second, even if we could, the re¬ 
sult would be a bloated interface re¬ 
flecting all possible uses of components. 



Figure 1: Class relationships using OMTnotation. 



Figure 2: Structure for the Extension Objects pattern. 


For example, a spell checker requires a 
specific interface to enumerate the words 
of a text component. The spell checker 
should operate on any component that 
provides this interface, independent of 
its concrete type. 

One solution is to provide a mechanism 
allowing clients to define additional inter¬ 
face extensions and to let clients query 
whether an object provides a certain ex¬ 
tension. 'fhere is a spectrum of techniques 
for how this mechanism can be imple¬ 
mented. 

The key idea is to define extensions to 
the interface as separate objects. The ex¬ 
tension object implements this extension 
interface, knows about the object it ex¬ 
tends, and implements the extension in¬ 
terface in terms of the extended object’s 
interface. Extensions themselves aren’t 
useful—there needs to be an interface 
that defines w r hich extension is provided 
by Component. For our purpose, the ex¬ 
tensions will be identified by a name. To 
avoid conflicts, this name should be reg¬ 
istered at a central place. A client can 
query whether a component provides a 
certain extension by calling the Get- 
Extension(extensionName) operation. If 
the component provides an extension 
with the given name, it returns a corre¬ 
sponding extension object. All extensions 
are derived from an abstract Extension 
class which provides only a minimal in¬ 
terface used to manage the extension it¬ 
self. For example, it can provide an op¬ 
eration that a Component can call to 
notify its Extensions when it is about to 
be deleted. 

In the case of the spell checker, we de¬ 
fine an extension named “TextAccessor.” 
The corresponding interface is defined by 
the abstract class TextAccessor. Its key op- 
eratioas are GetNextWordC), which returns 
the next word in the text, and Replace- 
CurrentWord(), to replace a misspelled 
word. Let’s assume that there are two dif¬ 
ferent implementations of text compo¬ 
nents: SimpleTextComponent and Fancy - 
TextComponent. Both components want 
to provide spell-checking support. To do 
so, both derive their own TextAccessor 
subclass that implements the interface for 
their text implementation. The Simple¬ 
TextComponent and FancyTextComponent 
classes implement GetExtensionC Text¬ 
Accessor”) to return their specific exten¬ 
sion object. 

Figure 1 summarizes the class relation¬ 
ships using OMTnotation (abstract opera- 
tioas and abstract classes are shown in ital¬ 
ics). The implementation of SimpleText 
Accessor:: Get Extension (...) is shown in Ex¬ 
ample 1. The extension object stores a ref¬ 
erence back to the extended object. It 
typically implements die extension by for¬ 
warding requests to die extended object. 


58 


Dr. Dobbs Sourcebook , May/June 1995 
























































































Based on this extension infrastructure, 
a spell checker for a compound document 
is implemented as follows: Traverse the 
components in the document. Ask each 
component for its TextAccessor extension* 
If the component returns a corresponding 
TextAccessor extension object, use it (after 
down casting it to TextAccessor) to spell 
check the component. Otherwise, skip the 
component and move on to the next. 

Applicability, You use the Extension 
Objects pattern when: 

• You need to support the addition of new 
interfaces, 

• An interface to an abstraction should 
not be tied to a specific, existing inher¬ 
itance hierarchy. 

• An abstract class has a large, bloated in¬ 
terface reflecting its use by multiple 
clients. 

Structure, The structure for the Exten¬ 
sion Objects pattern Ls shown in Figure 2, 
Participants. The participants for the 
Extension Objects patterns are: 

• ExtendedObject(ComponentX which de¬ 
fines an interface to query whether an 
object has a particular named extension. 

• Co ncreteExten ded Object (Fa n cy Text- 
ComgxjtmtiCimpIeTextCompmentX which 
returns appropriate extension objects 
when queried for a specific extension. 

• Extension (Extensio nX the common base 
class for all extensions. 

• SpecificExtensionCfextAccessorX which 
defines the interface of a specific ex¬ 
tension. 

• ConcreteExtension(Fa ncyTextA ccessor, 
SimpieTextAccessor), which implements 
the extension interface by calling open 
aborts on the ConcreteExtended object. 
To do so, it maintains a reference back 
to the ConcreteExtended object. 

Collaborations. The client negotiates 
with an Extended Object for a named ex¬ 
tension. If it exists, it is returned. The client 
subsequently uses the extension to access 
additional behavior of the ExtendedObject 
Consequences. The Extension Object 
pattern has several consequences: 

• The base class ExtendedObject does not 
require a large interface for all its clients. 
This avoids monolithic interfaces for the 
Extended Object. 

• Peer objects can use extension objects 
to negotiate a more specific interface (it 
could be more efficient or support bet¬ 
ter abstractions) between them. 

• An interlace is not attached to a particu¬ 
lar class definition. Classes providing an 
interface don't have to be related 
through inheritance. In die spell-checker 
example, text components don't have 
to inherit from a general TextCompo- 


rient base class, but they can still par¬ 
ticipate in sped checking, 

• An extended interface Is more compli¬ 
cated to use than one which is provid¬ 
ed by the extended object itself It re¬ 
quires more work to obtain the interface. 

Implementation, The implementation 
must define how die extension objects are 
managed by ExtendedObject, A simple so¬ 
lution is to store an extension object in an 
instance variable that is returned to clients 
when the extension is requested. An al¬ 
ternative is to dynamically allocate the ex¬ 
tension on demand when it is requested. 
A further variation is to provide support 
for clients to attach Extensions to existing 
objects. In this case, the Extended Object 
has to maintain a dictionary that maps an 
attached extension to its name. 

In C++, the extension returned from 
GetExtension has to be cast to its corre¬ 
sponding extension class. If the C++ im¬ 
plementation provides run-time type iden¬ 
tification, this can be achieved with 
dynamicjcast 

To permit the extension to have full ac¬ 
cess to the Extended object, it can be de¬ 
clared as its friend. 

Strings are a primitive way to identify 
extensions. Better soludons are to use spe¬ 
cial interface identifiers or some internal¬ 
ized form of strings. 

An alternative implementation is to use 
multiple inheritance and run-time type 
identification. An extension interface can 
be defined as a mixin class, .An object that 
supports a given extension inherits from 
this mixin class and implements the ex¬ 
tension. See Figure 3- 
The operations of die mixin class are 
all abstract and have to be implemented 


by derived classes. To query an object for 
an extension, the client uses run-time type 
information. For example, in C++, the spell 
checker would query a component 
whether or not it is (inherits from) a Text- 
Accessor; see Example 2, 

The use of a dynamic cast is often sus¬ 
picious and can point out a design flaw. 
However, in this case it is okay since a dy¬ 
namic cast is only used to ask an object 
whether it supports a certain interface. 

This pattern is less important in dynamic 
languages like Smalltalk, These languages 
typically provide enough run-time infor¬ 
mation to allow asking an object whether 
it responds to a specific request. 

Known uses. Support for extension in¬ 
terfaces is common in Compound Docu¬ 
ment architectures. The example from the 
Motivation discussion is based on Open- 
Doc. In OpenDoc, the common base class 
ODObject provides the access to the ex¬ 
tension interface. 

Extension objects are related to Mi¬ 
crosoft's Component Object Model (COM) 
and its Qwerylnterface mechanism, Query- 
Interface enables a client to query an ob¬ 
ject for an interface. In COM there Ls no 
extended object to sLart with, and all in¬ 
terfaces of an object are accessed by 
QuenJnterface 

Related patterns. One related pattern 
is Adapter which adapts an existing in¬ 
terface. Extension Objects provide addi¬ 
tional interfaces. 


DDJ 



Example 2: Querying a component. 
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SOFTWARE AND THE LAW 


Software Development 
Contracts 


I" V eveloping software under contract 
1 is a risky business. Software is 
1 rarely finished on time, cost over- 
* ' runs are common, and something 

invariably turns out not to work. 

A well-written development contract is 
essential to maintaining a good business 
relationship while you sail these stormy 
waters and to avoiding the expense and 
embarrassment of a lawsuit. Unfortunate¬ 
ly, software developers and their clients 
often do not give careful attention to their 
written contract until after a dispute aris¬ 
es. By then, it is usually too late. 

In this column, I’ll cover many of the 
most important clauses to consider. Re¬ 
vie w r diem now r , and save yourself trou¬ 
ble laterf 

Identify the Parties 

You would be amazed at the number of 
contracts that do not clearly identify" the 
parties to the contract. 

This is more than a mere matter of form. 
Only parties to a contract have die legal 
obligation to perform it and die legal right 
to receive its benefits. When a payment is 
not made, you want to be absolutely sure 
you know who owes that payment. Sim¬ 
ilarly, when the software tails or is not de¬ 
livered on time, you want to be sure diat 
you personally are not held liable w hen 
it is your company that is receiving the 
payment. 

The legal capacity of each party to a 
contract should be specified, as well as its 
exact legal name. Is it a corporation? Is it 
a partnership? Is it an individual doing 
business under a fictitious business name? 
All personal assets of an individual can 
usually be reached to satisfy a judgment 
against a fictitious name under which the 
individual is doing business. If a party 1 is 
a member of a larger corporate structure 
(for instance, a subsidiary), the contract 
should also make crystal clear w hich en- 
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dry within that structure is the contracting 
party. A parent is normally not liable for 
Lhe debts of its subsidiary, nor is a sub¬ 
sidiary normally liable for the debts of its 
parent. When contracting with a business 
that has limited assets, consider asking for 
one or more personal guarantees. 

Scope of Work 

You would never go to a dealer and buy 
a new car without carefully reviewing its 
list of options. Yet, software development 
often proceeds without the parties first hav- 
ing made sure that they each have the 
same understanding of what will be done. 
Sudi a blind approach is a time bomb w ait- 
ing to explode. Don’t let it happen to you. 

Detail in w riting the functions the soft¬ 
ware is expected to perform and the re¬ 
sults it is expected to achieve. Sufficient¬ 
ly detailed specifications provide dear, 
objective standards by which the softw are 
can be judged. The more expensive the 
contract, the greater the detail. Don’t for¬ 
get to specify the operating environment, 
including hardware (processor type, RAM 
size, storage speed/size, and so on), op¬ 
erating system(s), and necessary (.and pro¬ 
hibited) peripherals. 

Li many cases, die development of diese 
specifications constitutes part of the work 
for w liich the software developer has been 
hired. In these situations, the specific de¬ 
tails are not known at die time the con¬ 
tract is signed; nevertheless, general guide¬ 
lines should be specified in writing, r l1ie 
contract should also contain a clause re¬ 
quiring die developer to later present the 
detailed specifications in w riting to the 
client for review and written approval. 

The contract should address whether 
the develojier will be providing any ser¬ 
vices or materials beyond the softw are it¬ 
self. For example, will the developer be 
converting existing data to run with the 
new software? Must he install the software, 
train users, or provide other user support? 
Must he be available to make upgrades? 

One important area often not clearly 
delineated concerns documentation. Must 



the developer provide user manuals? Must 
tie provide documentation sufficient to en¬ 
able another developer to continue w ith 
the development, such as source-code list¬ 
ings, descriptions of subroutines, data de¬ 
scriptions and standards, and flowcharts? 
Clients often do not realize the importance 
of this material until long after the con¬ 
tract is signed Developers, on the other 
hand, know that these materials are ex¬ 
pensive to provide and sometimes use si¬ 
lence as a vehicle to omit them. Thai is a 
mistake. The contract should clearly spec¬ 
ify the documentation the developer will 
provide and the documentation he will not. 

Modifications 

Invariably, changes in die software w r ill 
be requested during development, as well 
as changes in the associated materials and 
services that the developer is to provide. 
Unless documented in w riting, misunder¬ 
standings concerning the costs and dead¬ 
lines for making diese changes may arise. 

The contract should include a clause 
requiring all changes to the contract to lie 
recited in writing Lind initialled by all par¬ 
ties. In addition to specifying the exact 
nature of the change, the wilting should 
set forth whether the developer will re¬ 
ceive any additional compensation for the 
change or additional time for making it. 
For the protection of the developer, the 
contract should provide that the develop¬ 
er is not obligated to make any change 
nor agreed upon in writing. To protect the 
client, the contract should provide diaL die 
developer w ill not lie paid or receive ad¬ 
ditional time for any change not approved 
by die customer in writing. 

Customer Responsibilities 

Cooperation with the client is often re¬ 
quired during die development of the soft¬ 
ware. For example, die developer may 
need to meet w ith die client’s staff to de¬ 
termine die opera donal requirements for 
the software and to review the develop¬ 
er’s proposed specifications. The devel¬ 
oper may also need access to the cus¬ 
tomer’s equipment. 

The contract should specify each re¬ 
quired area of client cooperation. The 
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more detailed the specification in terms 
of time and frequency, the better. With¬ 
out this clause, it may be difficult for the 
developer to later excuse a delay in de¬ 
livery caused by a lack of cooperation on 
the part of the customer. 

Scheduling 

Another fertile area for misunderstanding 
is scheduling. 'Ibe client often has one ex¬ 
pectation, the developer another. A good 
contract should never allow this to occur. 

Deadlines for all stages of the softw are 
development should be specified. If the 
developer is to design the specifications, 
when will they be presented to the cus¬ 
tomer? How long does the client have to 
approve them? When will the first version 
of the software lx? ready for testing? How 
long w ill it lx? tested? When will the test¬ 
ed softw are be finished, fully operational, 
and ready for delivery? How' long will the 
developer have to correct bugs that are 
discovered later? 

Deliverables 

A specification of what is to lx? delivered 
is just as important as a specification of 
when delivery is required. The contract 
should clearly describe exactly what the 
developer is to deliver. In addition to ob¬ 


ject code, is he to deliver source code? 
Also, w r hat fonn will the delivery take? Will 
the software and documentation be on a 
floppy, CD-ROM, or tape? 

Some contracts provide that the devel¬ 
oper need not deliver the source code to 
the client. This approach forces the cus¬ 
tomer to use the developer for upgrades 
to the software and, as a practical matter, 
to fully pay for the software to get post¬ 
delivery help. For the protection of the 
customer, the contract should require the 
developer to deposit a copy of the source 
code with an escrow with instructions to 
turn die source code over to the customer 
if the developer breaches or is otherwise 
unable to continue his performance. 

Payment 

Payment, of course, is usually the only 
topic given consideration by the develo¬ 
per. Naturally, the contract should be dear 
about it. 

The contract should specify the basis of 
the payment. If it Is a fixed-price contract, 
diat price, of course, should lx? specified. 
If based on time, die hourly rates of die var¬ 
ious individuals (or classes of individuals) 
should lx? specified. If reimbursement for 
expenses can lx* requested, the types of re¬ 
imbursable expenses should lx? itemized. 


The deadlines for making payment 
should also be clearly specified. Most 
agreements provide for a series of pay¬ 
ments, including an initial payment when 
the contract is signed. For substantial pro¬ 
jects, it is often also useful to require die 
developer to provide detailed reports and 
invoices as a condition to each payment. 
This ensures the customer that the devel¬ 
oper is on schedule and reduces the 
chance of the customer raising an objec¬ 
tion to an allegedly problematic matter 
that was clearly disclosed in an earlier re¬ 
port or invoice. 

Validation, Verification, and 
Testing 

Customers usually w'ant the contract to 
provide that their final payment is subject 
to some form of validation, verification, 
and testing. This is usually a fair request 
w hich cannot easily be refused. 

Hut safeguards can and should be built 
in. 'Ihe contract should specify’ the types 
of tests w'hich w ill be done, the identity 
of the testers, who w ill pay for the ex¬ 
pense of the test, and how much time will 
be allowed for the test. Most importantly, 
the contract should specify an objective 
standard by w'hich the success of the test 
can be measured. 
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Customers would be wise to insist upon 
the software being tested by someone oth¬ 
er ilian the software developer In addition 
Lo obvious bias, the developer often fails 
to operate the software in the sequences 
that cause a problem. After all, tine devel¬ 
oper usually designed the software to han¬ 
dle all of the operational sequences that 
he or she can foresee. Someone other tlian 
the developer may well operate the soft¬ 
ware in an unforeseen sequence, and it is 
this type of unforeseeable sequence that 
needs to be tested the mast. 

Ownership 

The agreement should dearly specify who 
owns die intellectual property that relates 
to the development work, as well as the 
tangible materials that are received or cre¬ 
ated in connection with the developer’s 
w r ork. This includes rights to copyrights, 
patents, and trade secrets. A variety of spe¬ 
cialized concerns might need to be ad¬ 
dressed. 

One such concern arises when the de¬ 
veloper uses independent subcontractors. 
Under copyright law, title to a copyright 
created by an independent contractor will 
usually not pass to either the developer 
or the customer unless the independent 
contractor signs an agreement promising 


to assign that copyright; If the customer 
wants to retain ownership of all copyrights 
in the developed software, the contract 
should require the developer to procure 
such written subcontracts with each in¬ 
dependent subcontractor. Even in the ab¬ 
sence of a requirement for such subcon¬ 
tracts, the developer would be wise to 
nevertheless procure them. Otherwise, he 
might tie unable to deliver full title to the 
customer and hence be in breach of his 
obligation to do so. 

Developers often use in-house subrou¬ 
tines in their software. If the developer 
wishes to retain the right to continue to 
use these subroutines in connection with 
software for other customers, the agree¬ 
ment should provide that ownership of 
these subroutines remain w'ith the devel¬ 
oper. Similarly, the agreement should ex¬ 
cuse the developer from delivering title to 
underlying commercial products that the 
developer has chosen to incorporate into 
his design. 

Sometimes, the customer may want to 
modify the software. The agreement 
should specify whether the customer has 
this right and, if so, who owns the result¬ 
ing work. 

In general it is normal for the customer 
to obtain all rights in original software pur¬ 


chased for resale. On Llie other hand, die 
customer usually receives only a license 
(w ith the developer retaining title) to soft¬ 
ware developed merely for use by the cus¬ 
tomer, When only a use license is grant¬ 
ed, the contract should specify whether 
the customer has the right to transfer his 
license to another and whether die de¬ 
veloper is then entitled to receive addi¬ 
tional compensation. 

Confidentiality 

Customers often provide developers w ith 
highly sensitive information during de¬ 
velopment. Developers similarly often pro¬ 
vide customers with equally sensitive 
information, sometimes including the soft¬ 
ware itself. When this occurs, die customer, 
developer, or both may often want that 
confidential information to be protected. 

The contract should require that the 
customer, developer, or both use reason¬ 
able efforts to protect die confidentiality 
of diis information, it should further pro¬ 
vide that the party providing the protec¬ 
tion will not use or disclose die confi¬ 
dential information to others, except to 
reasonably further his performance under 
the contract. All confidential information 
dial is to be protected should be specifi¬ 
cally identified, 
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A “confidentiality” clause should be in¬ 
cluded, even when the parties have a liigh 
degree of confidence in each other’s in¬ 
tegrity and competency. The absence of 
a “confidentiality” clause is often cited by 
courts as a reason for refusing to protect 
what otherwise would be enforceable 
rights in trade secrets. 

Noncompetition 

Another approach often used to protect 
the value of die software is to include a 
clause prohibiting the developer from de¬ 
veloping similar software for a competitor 
or from direcdy competing with the cus¬ 
tomer. These clauses will be enforced in 
many states if they are reasonable— that 
is. if they are limited in duration, geograpltic 
area (when appropriate), and areas of com¬ 
petition. I lowever, in some suites (Califor¬ 
nia, for example), even reasonable restraints 
on competition will usually not be en¬ 
forced. If you have made a noncompeti¬ 
tion promise that you no longer wish to 
honor, legal research can determine 
whether you are likely to lx* bound to it. 

Developer Assurances 

Normally, the contract provides that the 
software will conform to the agreed-upon 
specifications, meaning, of course, that it 
will work. A clause is sometimes includ¬ 
ed also making die developer liable if the 
software infringes a patent, trademark, 
copyright, or trade secret owned by an¬ 
other. Liability may also lx* imposed upon 
a developer who fails to deliver the soft¬ 
ware on lime. 

In many instances, these liabilities will 
be imposed upon the developer, even if 
he or she does not expressly promise to 
assume them in the contract. 

Disclaimers 

Read this section carefully! 

The liability imposed upon the devel¬ 
oper may often far exceed the amount of 
money the developer is paid. 

What can developers do to protect 
themselves? The answer can lx? suited in 
diree words: Disclaim, disclaim, disclaim! 

The contract can disclaim all liability for 
what is known as “consequential dam¬ 
ages**— damages caused by defective soft¬ 
ware or its late delivery, such as lost prof¬ 
its, injury to reputation, and damage to data. 

Tile contract might also provide that the 
developer is to correct any deficiencies in 
the software within a suited number of 
days after they are brought to the devel¬ 
oper’s attention, and that such correction 
is the sole and exclusive remedy that the 
customer has for a defect in the software. 
The contract might also limit the period 
of time following completion of the soft¬ 
ware during which the developer shoul¬ 
ders this responsibility. 


The legal capacity 
of each party to 
a contract should 
be specified 


Courts do not always enforce dis¬ 
claimers. Usually, a court will refuse to en¬ 
force a disclaimer for one of three reasons: 

• The disclaimer was not sufficiently con¬ 
spicuous. 

• The disclaimer did not use the right lan¬ 
guage. 

• The law of the state governing the con¬ 
tract provides that the disclaimer is un¬ 
enforceable. For example, most suites will 
not enforce a disclaimer when its effect 
would be to excase liability for personal 
injury caused by a defect in the software. 

Insurance 

Another method to protect against large 
liabilities is to require liability insurance 
to lx purchased. The customer can be re¬ 
quired to make the purchase and to name 
the developer as an ‘additional insured” 
or vice versa. Sometimes, a customer’s ex¬ 
isting commercial general-liability policy 
can lx inexpensively amended to name 
the developer as an “additional insured.” 
Tlie type of liability that must lx insured 
should also be specified. 

Breach 

In the absence of express language, a ma¬ 
terial breach provides the aggrieved par¬ 
ty with the right to stop performance. 
Thus, if the customer misses a payment, 
the developer can usually stop work. On 
the other hand, if the software is behind 
schedule or Is not working, the customer 
can often stop making payments. 

These legal rights can and often are 
modified by the contract. For example, 
the contract can lx w ritten to give the de¬ 
veloper a stated number of days follow¬ 
ing written notice of a defect or untimely 
delivery to cure that problem before the 
customer can start w ithholding payment. 
The contract can similarly give the cus¬ 
tomer a stated number of additional days 
to make a late payment after receiving a 
late-payment notice from the developer, 
before the developer can stop work. 

Liquidated Damages 

It is usually difficult for both parties to the 
contract to predict the damages that might 


arise because of a breach in performance. 
This is particularly true for the developer. 

To limit liability, a “liquidated damages” 
provision is sometimes inserted. Such a 
clause specifies an exact amount of mon¬ 
ey that die customer will receive because 
of certain breaches by the developer. For 
example, it may provide that the customer 
will receive $100.00 for each day the soft¬ 
ware is late or $500.00 for each defect in 
the software. If both parties are reason¬ 
able, the use of a “liquidated damages” 
provision often eliminates disputes that 
otherwise might arise. 

Arbitration and Attorney Fees 

Development contracts sometimes provide 
that all disputes arising in connection with 
the contract must be resolved by arbitra¬ 
tion, rather than court litigation. Arbitra¬ 
tion is usually faster and far less expen¬ 
sive than court litigation. 

The contract can also contain a clause 
providing tlx prevailing party with an award 
of reasonable attorney fees, in addition to 
all other relief, whether the dispute is re¬ 
solved by arbitration or court litigation. 

It is often difficult to predict whether 
either of these clauses wall be beneficial. 
Among the factors considered are the rel¬ 
ative wealth of the parties and the per¬ 
ceived likelihood of one side being more 
litigious than the other. 

Merger Clause 

Most gcxxJ contracts contain what Is called 
a “merger clause.” 'This clause provides 
that the software-development contract 
contains all terms of the contract between 
the parties and all representations that 
each is making. The clause can also pro¬ 
vide that any statements that may have 
been made in the past by either party do 
not form a pan of the contract and that 
no party is relying upon any such past 
statement in entering into the contract, un¬ 
less it is expressed in the contract. Final¬ 
ly, the clause usually provides that no 
modification to the contract will be ef¬ 
fective unless the modification is in writ¬ 
ing and signed by both parties. 

The value of this clause is obvious. 
Don’t overlook it! 

Conclusion 

A carefully thought-out contract should 
lie at die foundation of every independent 
software-developnxnt project. At all times, 
lx comprehensive, specific, and reason¬ 
able. If these three rules are followed, the 
contract will nurture the business rela¬ 
tionship like a marriage counselor and, if 
necessary, wrill pave the way for a clean 
divorce without expensive and embar¬ 
rassing litigation. 

DDJ 
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create your own spitfire'paced, 
spine-tingling maze games. This 
book/disk package blows the 
lid off the maze game program¬ 
ming mystery, and gives you 


: D yi.CJ.E0 C-AWFS.ri 


Take an in-depth, behind-the- 
scenes tour of writing 3D video 
games with Borland C++. Learn 
iplete, full-featured 


to build o com| 

Right simulator, modeled after 
the one included on the disk. 
$34.95. 


everything you need to create 


your own maze environments. ^ 

S3 4.95 


DESIGN YOUR OWN DiSTRUCttCtN 
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